The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Использование похожих Unicode-символов для обхода аутентификации

17.12.2019 09:59

GitHub оказался подвержен атаке, позволяющей захватить доступ к учётной записи через манипуляцию с Unicode-символами в email. Проблема связана с тем, что некоторые символы Unicode при применении функций преобразования в нижний или верхний регистр транслируются в обычные символы, близкие по начертанию (когда несколько разных символов транслируются в один символ - например, турецкий символ "ı" и "i" при приведении в верхний регистр преобразуются в "I").

Перед проверкой параметров входа в некоторых сервисах и приложениях переданные пользователем данные вначале преобразуются в верхний или нижний регистр, а затем проверяются в БД. Если сервис допускает применение unicode-символов в логине или email, то атакующий может использовать похожие unicode-символы для совершения атаки, манипулирующей коллизиями в таблицах преобразования регистра символов (Unicode Case Mapping Collisions).


   'ß'.toUpperCase() == 'ss'.toUpperCase() // 0x0131
   'K'.toLowerCase() == 'K'.toLowerCase() // 0x212A
   'John@Gıthub.com'.toUpperCase() == '[email protected]'.toUpperCase()

В GitHub атакующий мог через форму восстановления забытого пароля инициировать отправку кода восстановления на другой email через указание в форме адреса, включающего unicode-символ, вызывающий коллизию (например, вместо [email protected] указывался email mı[email protected]). Адрес проходил проверку так как преобразовывался в верхний регистр и совпадал с результатом преобразования исходного адреса ([email protected]), но при отправке письма подставлялся как есть и код восстановления уходил по поддельному адресу (mı[email protected]).

Некоторые из символов, вызывающих коллизии при преобразовании регистра:


   ß 	0x00DF 	SS
   ı 	0x0131 	I
   ſ 	0x017F 	S
   ff 	0xFB00 	FF
   fi 	0xFB01 	FI
   fl 	0xFB02 	FL
   ffi 	0xFB03 	FFI
   ffl 	0xFB04 	FFL
   ſt 	0xFB05 	ST
   st 	0xFB06 	ST
   K 	0x212A 	k


  1. Главная ссылка к новости (https://news.ycombinator.com/i...)
  2. OpenNews: Новый метод фишинга с использованием unicode-символов в домене
  3. OpenNews: Уязвимость, позволяющая отобразить иной домен в адресной строке браузера
  4. OpenNews: Релиз WordPress 4.2 с устранением серьёзной уязвимости
  5. OpenNews: Оценка типичных проблем с безопасностью для различных языков программирования
  6. OpenNews: Поддельное приложение WhatsApp в Google Play установили более миллиона пользователей
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/52047-unicode
Ключевые слова: unicode
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (7) RSS
  • 1.1, helgi (??), 14:59, 19/12/2019 [ответить]  
  • +3 +/
    'ß'.toLowerCase() === 'SS'.toLowerCase()
    false
    'John@Gıthub.com'.toUpperCase() === 'John@Github.com'.toUpperCase();
    true

    Отправлять письмо по введенному адресу, а не по тому, что был найден в базе? Ну, ок.

     
     
  • 2.2, svsd_val (ok), 15:18, 19/12/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Более того она нелепа =)
     
  • 2.4, Аноним (4), 01:58, 20/12/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    toUpperCase в обоих случаях
     

  • 1.3, Xasd (ok), 21:45, 19/12/2019 [ответить]  
  • +6 +/
    > Адрес проходил проверку так как преобразовывался в верхний регистр и
    > совпадал с исходным адресом (mike@example.org ), но при отправке
    > письма подставлялся как есть и код восстановления уходил по
    > поддельному адресу (mıke@example.org

    корень (краеугольная причина!) этой проблемы в том что в ряде случаев в базах данных хранятся (опрометчиво) только "нормализированный-варианты-email".

    но при отправке -- сервис справедливо хочет использовать "оригинальный-вариант-email" а не "нормализированный", на случай вдруг нормализация испортила свойства этого email.

    а откуда взять "оригинальный-вариант-email" если он не был сохранён?! вот программисты и решили (опрометчиво!) что ЯКОБЫ могут взять его прямо сразу из формы ввода пользователя. хитрые какие :-) ..

    вот и выводы -- либо сохраняйте в базе данных сразу оба варианта email...

    ...и в любом случае после процесса верификации email -- имейте точно ввиду что-же-именно вы верифицировали.

    фраза звучит бонально, но всё же программистам в неё нужно вдуматься:

    процесс ВОССТАНОВЛЕНИЯ пароля -- должен ВТОЧНОСТИ быть непротеворечивым по отношению к процессу ВЕРИФИКАЦИИ email! то есть: какой email верифицировался -- вот именно он (а не якбы его "эквивалентные" версии) и должен быть использован для восстановления пароля.

     
  • 1.5, Аноним (-), 17:24, 21/12/2019 [ответить]  
  • +1 +/
    Весьма древняя проблема. И она принципиально не лечится.

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

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру