Кратко

  • Индивидуальный Internet-Draft от 27 октября рассматривает имитацию поддержки и рекрутеров в сообщениях площадок занятости, торговли и образования. Он предлагает инженерные проверки, не создавая протокол.
  • Проект выделяет две ловушки: строгое совпадение Unicode-«скелетов» может не заметить визуально близкое имя, а некоторые обследованные валидаторы, по словам автора, принимают хосты с сохранёнными невидимыми знаками. Проверять нужно отправителя, ссылку и цель сообщения вместе.

Сообщение приходит в личный кабинет торговой площадки. Поле имени отправителя гласит «Служба поддержки». Для получателя это похоже на должность; для системы пока лишь строка, которую указало какое-то учётное имя. Новый проект о похожих отправителях предлагает анализировать конкретную переписку: адрес, отображаемое имя, хост ссылки и просьбу к читателю. Корпоративный почтовый шлюз получателя не стоит между двумя аккаунтами одного приложения. Площадка сама знает, какие аккаунты вправе носить её знак поддержки.

Автор собирает три слоя признаков. Сравнить домен отправителя и хост ссылки с защищёнными именами. Проверить, не появилось ли фирменное слово в чужом адресе или отображаемом имени. Оценить действие, которого добивается сообщение: пароль, уход с площадки, подчинение якобы официальному распоряжению. Вместе эти признаки сильнее, чем поодиночке. Университетский карьерный центр вправе говорить языком рекрутеров; автоматическая блокировка каждого похожего имени ударит и по нему.

Первая техническая ошибка прячется в знаке равенства. Unicode UTS #39 определяет «скелет» для сопоставления сходных символов и проверку смешения письменностей. В проекте объясняется, почему только точное равенство скелетов пропускает часть зрительных имитаций: малая греческая каппа и малая кириллическая «тэ» отображаются в латинские прототипы вне ASCII. Скелет поддельного имени может отличаться от ASCII-написания марки, хотя глаз их сближает. Проект предлагает добавить анализ письменностей и ограниченное редакционное расстояние между скелетами.

Во второй ошибке символ вообще не виден. Автор пишет, что несколько валидаторов из его обзора приняли хосты с U+00AD, U+200B, U+2060 или U+FEFF и вернули значение с этим символом внутри. RFC 5890 задаёт рамку IDNA, RFC 5892 правила для кодовых точек, а Unicode UTS #46 — совместимую обработку. Проект советует обработать хост по IDNA2008 или UTS-46 до сравнения с разрешённым списком и отвергать метки с форматными либо игнорируемыми по умолчанию символами. Валидатор, который сообщает «допустимо» и передаёт дальше исходную невидимую примесь, выдаёт пропуск не тому объекту.

Реестр доменов не знает, какому аккаунту этой площадки поручили отвечать от её имени. Оператор знает список официальных имён, историю учётных записей и последствия тревоги: показать предупреждение, остановить ссылку или заблокировать сообщение. Проект допускает языковую модель для контекста, но требует считать текст сообщения недоверенным входом и не отдавать модели право отменять детерминированные факты об отправителе. Datatracker по-прежнему показывает индивидуальный проект I-D Exists с предполагаемым статусом Informational.

В тексте нет списка обследованных библиотек с версиями и воспроизводимой таблицы входов и выходов. Такая таблица показала бы, где описанный сбой сохраняется сегодня.