Назад

Как искать несоответствия универсальному принятию

29.10.2020

Как известно, проект Поддерживаю.РФ включает программу IDN Bug Bounty, которая позволяет зарабатывать не поиске несоответствий универсальному принятию. Для участия в ней необходимо пройти короткий онлайн-курс, прочитать правила программы и довольно длинную методику тестирования.

После этого можно приступать к непосредственному тестированию программного обеспечения, приложений, сервисов или наиболее популярных российских веб-сайтов на соответствие универсальному принятию и направлять нам полученные результаты.

Многих отпугивает такое количество документов, хотя на самом деле все довольно просто. Самый короткий перечень несоответствий универсальному принятию, которому можно следовать при проверке любого ПО, приложения, сервиса или веб-сайта приведен в двух документах «лучшие практики универсального принятия» и «плохие практики универсального принятия».

Если предельно упростить написанное там, то есть следующие наиболее важные несоответствия универсальному принятию:

  • Интерфейс тестируемого продукта и обработчики ошибок должны позволять вводить IDN-домены, а также основанные на них EAI адреса электронной почты, как полные (тест@поддерживаю.рф), так и неполные (test@поддерживаю.рф) – забегая вперед, это самая распространенная проблема. Если ввод IDN/EAI-адресов невозможен, такой продукт получает статус «Не поддерживает IDN/EAI»;
  • В полях интерфейса, выводящих URL, не должен отображаться Punycode, а введенные ACE-метки после обработки должны возвращаться в Unicode. Если этого не происходит, но при этом продукт работает с URL, содержащими IDN-домены и EAI-адреса, он получает статус «Частично поддерживает IDN/EAI»;
  • Почтовые сообщения на EAI адреса (например, тест@поддерживаю.рф или test@поддерживаю.рф) должны отправляться, а направленные с таких адресов (если продукт подразумевает прием e-mail) приниматься. Идеально, если имя отправителя (указанное до знака @) отображается в Unicode, если это не так, то неидеально, но на данном этапе допустимо, чтобы почтовые сообщения на такие адреса отправлялись и принимались. Если почтовые сообщения на EAI адреса не отправляются или не принимаются с них, такой продукт получает статус «Не поддерживает IDN/EAI». Если почтовые сообщения отправляются и принимаются, но отображение адреса электронной почты происходит с использованием Punycode в доменной части (после знака @), то такой продукт получает статус «Частично поддерживает IDN/EAI», при условии, что выполняются требования по вводу адресов и URL.

Поиск несоответствий на примере CMS WordPress

Все эти аспекты легко проверить, не разбираясь в коде приложения или сервиса. Рассмотрим это на примере CMS WordPress, который есть в каталоге продуктов проекта Поддерживаю.РФ со статусом «Частично поддерживает IDN/EAI».

1. Скачаем последнюю версию WordPress

Развернем ее на хостинге или локальном компьютере (мы использовали версию 5.5.1), привязав кириллический домен, чтобы сразу увидеть связанные с этим проблемы.

В процессе установки сразу же проверим позволяет ли CMS использовать кириллический логин администратора и EAI-адрес для него.
Как мы видим из описания поля, кириллический логин администратора не разрешен. Соответственно, говорить о полной поддержке универсального принятия уже не приходится.

Также этот факт с небольшой натяжкой (так как он касается логина администратора, а не IDN домена или EAI адреса электронной почты), но является несоответствием продукта CMS WordPress универсальному принятию, который можно загрузить в нашу программу IDN Bug Bounty как баг № 1.
После заполнения поля «Ваш e-mail» мы видим, что для e-mail администратора полный EAI-адрес (типа инфо@поддерживаю.рф) также не разрешен. Однако частичный EAI (типа info@поддерживаю.рф) проходит проверку.

С точки зрения универсального принятия, это безусловный баг, также заслуживающий загрузки в IDN Bug Bounty как баг № 2.

Письмо на частичный EAI-адрес (типа info@поддерживаю.рф) приходит, хотя адрес отправителя отображается с использованием Punycode в доменном имени, что также говорит о неполной поддержке универсального принятия.
Помимо этого, мы видим, что в тексте письма домен сайта и все связанные с ним URL отображаются в Punycode, что говорит о том, что хранится домен сайта в ASCII.

И, как мы знаем, появление любого Punycode как на страницах, так и в шаблонах e-mail, также подходит для отправки в IDN Bug Bounty. И это баг № 3.

2. Создадим страницу «о проекте» с кириллическим URL и посмотрим, как она отображается.

Мы видим, что в целом с отображением кириллического URL проблем нет.
Однако в административной части видны сразу несколько проблем. Во-первых, это Punycode в URL страницы (баг № 4), а во-вторых, странное поведение CMS при попытке задать произвольный кириллический ярлык URL (он не сохраняется при снятии фокуса с поля ввода) – баг № 5. И то, и другое может быть передано в IDN Bug Bounty.

3. Перейдем в консоль WordPress.

Поскольку мы уже выяснили, что WordPress в обязательном порядке преобразует IDN-домены в Punycode, попробуем понять, в какой момент это происходит и можно ли это изменить.
Мы видим, что в настройках URL сайта отображается в Punycode, что не соответствует принципам универсального принятия, однако e-mail отображается правильно. Проведем эксперимент и введем доменное имя в Unicode.
Ввод был разрешен, доменное имя теперь отображается правильно, причем не только в консоли, но и на странице редактирования записи. Делаем вывод, что трансляцию имени сайта в Punycode произвел скорее всего скрипт-инсталлятор – эта информация пригодится нам при работе с кодом CMS и может быть добавлена в описание бага в IDN Bug Bounty.

4. Проверим остальные страницы административного раздела WordPress

Здесь мы видим, что в списке пользователей домен в EAI-адресе также отражается в Punycode.
Информацию об этом можно загрузить в IDN Bug Bounty как баг № 6.

Кроме того, попытка создать другого пользователя с кириллическим логином и полным EAI-адресом также заканчивается сообщением об ошибке.
Хотя это не является отдельной ошибкой, а повторяет баги № 1 и 2, теперь мы понимаем, что в отличие от бага № 4, код, вызывающий баги 1 и 2 находится в ядре CMS.

Как загружать баги в программу IDN Bug Bounty

Напомним, что открытая в рамках нашего проекта Поддерживаю.РФ программа IDN Bug Bounty позволяет зарабатывать на поиске несоответствий универсальному принятию. До конца 2020 года каждый месяц тот, кто добавит больше всего обнаруженных багов за месяц, получает 45 тыс. рублей (до вычета налогов).

Для того чтобы добавлять баги и участвовать в программе IDN Bug Bounty нужно:

  1. Пройти регистрацию на сайте Поддерживаю.РФ;
  2. Ознакомиться с правилами программы IDN Bug Bounty;
  3. Пройти бесплатный учебный курс «Введение в универсальное принятие» и сдать тест по нему;
  4. Загружать в каталог сайта новые продукты и обнаруженные в них несоответствия универсальному принятию (баги).

Добавить или «загрузить» информацию о несоответствии универсальному принятию какого-либо продукта или крупного веб-сайта просто!

1. Нужно проверить, присутствует ли анализируемый вами продукт в нашем каталоге. Если его нет, то воспользоваться пунктом «добавить продукт» в главном меню. В открывшейся форме добавления продукта нужно указать его название, заполнить краткое описание, добавить логотип и ссылку на сайт производителя, а также отметить, является ли он СПО (Open Source). Не забудьте указать самое главное - насколько продукт поддерживает IDN/EAI. Модерация занимает несколько часов и после ее прохождения продукт появится в Каталоге.

2. После появления вашего продукта в каталоге, вы можете добавлять конкретные несоответствия непосредственно в его карточке. Для этого необходимо после авторизации на сайте, выбрать нужный продукт и нажать внизу кнопку «принять участие». Если вы прошли курс «Введение в универсальное принятие» и успешно сдали тест по нему, то в карточке продукта вам откроется раздел «Идеи и доработки», где и необходимо добавлять информацию о найденных багах.

Для того чтобы добавить описание бага, нажмите на кнопку «Новая идея» и введите название и краткое описание обнаруженной проблемы.

Не забывайте также добавлять скриншоты, чтобы продемонстрировать, где именно был обнаружен баг. Например, для бага № 1 (невозможность создать пользователя с кириллическим именем) это может выглядеть так: После нажатия на кнопку «предложить» информация о баге сохранится и будет видна всем участникам программы IDN Bug Bounty, которые в дальнейшем смогут голосовать за нее или оставлять свои комментарии.

Как подводятся ежемесячные итоги в программе IDN Bug Bounty

Количество найденных каждым участником несоответствий универсальному принятию ежемесячно оценивается организаторами программы IDN Bug Bounty следующим образом:

  • Каждое добавленное несоответствие уже существующего в каталоге продукта 1 балл;
  • Каждый добавленный в каталог продукт, не поддерживающий или частично поддерживающий универсальное принятие 3 балла;

В каталог могут быть добавлены - программное обеспечение, сервис или веб-проект. К участию в программе принимаются веб-проекты (веб-сайты), посещаемость которых по данным сервиса Similarweb.com составляет не менее 30 тыс. уникальных пользователей ежемесячно.

Участник, который добавит больше всех информации о найденных несоответствиях и соберет не менее 50 баллов за календарный месяц – получит 45 тыс. рублей (до вычета налогов).

Подробная информация об условиях программы находится здесь.

Другие новости раздела

Пользователи смогут проверить готовность почтовых сервисов к работе с кириллическими e-mail
Пользователи смогут проверить готовность почтовых сервисов к работе с кириллическими e-mail
28.10.2021
Любой пользователь может написать письмо на тестовый адрес электронной почты и получить автоматический ответ.
Опубликован ежегодный отчет UASG о готовности к универсальному принятию
Опубликован ежегодный отчет UASG о готовности к универсальному принятию
25.10.2021
В этом году оценивались популярные языки программирования, утилиты, CMS WordPress, а также почтовые клиенты и серверные решения.
Теперь можно пожаловаться на отсутствие поддержки кириллицы
Теперь можно пожаловаться на отсутствие поддержки кириллицы
30.09.2021
Поддерживаю.РФ запустил сервис сбора жалоб на проблемы с поддержкой кириллических доменных имен и почтовых адресов.
Новый полезный сервис
Новый полезный сервис
25.09.2021
В разделе «Полезные сервисы»  появился сервис перевода  доменного имени из Unicode в ASCII-представление и обратно.
Опубликованы новые рекомендации по поддержке доменных имен и адресов электронной почты на кириллице
Опубликованы новые рекомендации по поддержке доменных имен и адресов электронной почты на кириллице
27.08.2021
Документ разработан предназначен для разработчиков программного обеспечения, поддерживающего любые российские кириллические домены.
Инфраструктура интернета все ближе к универсальному принятию
Инфраструктура интернета все ближе к универсальному принятию
15.08.2021
Опубликован отчет UASG, посвященный результатам тестирования почтовых серверов, спам фильтров и библиотек.
«1C-Битрикс: Управление сайтом» поддерживает кириллические почтовые адреса
«1C-Битрикс: Управление сайтом» поддерживает кириллические почтовые адреса
27.07.2021
В версию v21.300.0 главного модуля вошло обновление функций, отвечающих за работу с IDN-доменами в e-mail.
Запущен сервис тестирования EAI-адресов на 28 языках
Запущен сервис тестирования EAI-адресов на 28 языках
20.07.2021
Он позволяет проверить готовность e-mail провайдера к работе с  интернационализированными почтовыми адресами (EAI).