Назад

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

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 тыс. рублей (до вычета налогов).

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

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

Готовые библиотеки Java, Python и JavaScript для валидации IDN-доменов и EAI
Готовые библиотеки Java, Python и JavaScript для валидации IDN-доменов и EAI
28.03.2024
Обзор известных библиотек на распространенных языках программирования
На сайте появился новый раздел «Часто задаваемые вопросы»
На сайте появился новый раздел «Часто задаваемые вопросы»
25.03.2024
Подготовили ответы на популярные вопросы об универсальном принятии и не только
День универсального принятия в Белграде
День универсального принятия в Белграде
21.03.2024
Глобальный Universal Acceptance Day пройдёт 28 марта в Сербии
IT-системы корпорации ICANN готовы к работе с EAI адресами электронной почты
IT-системы корпорации ICANN готовы к работе с EAI адресами электронной почты
26.01.2024
Решение проблемы универсального принятия в ICANN заняло почти 14 лет
Популярные у россиян сайты прошли проверку на работу с кириллическими e-mail адресами
Популярные у россиян сайты прошли проверку на работу с кириллическими e-mail адресами
11.12.2023
Публикуем результаты нового исследования
В панели управления хостингом ispmanager внедрили поддержку кириллической почты
В панели управления хостингом ispmanager внедрили поддержку кириллической почты
13.11.2023
Публикуем инструкцию как создавать кириллические почтовые адреса в ispmanager
Студенты МТУСИ изучили основы интернационализации доменной и почтовой адресации в сети интернет
Студенты МТУСИ изучили основы интернационализации доменной и почтовой адресации в сети интернет
27.10.2023
Поддерживаю.РФ продолжает повышать навыки молодых IT специалистов в области универсального принятия IDN и EAI
Неделя интернета в Карелии: лекции для студентов ПетрГУ
Неделя интернета в Карелии: лекции для студентов ПетрГУ
12.09.2023
Эксперты Поддерживаю.РФ прочитали лекции студентам ПетрГУ