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

17.12.2019 09:59

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

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


   'ß'.toUpperCase() == 'ss'.toUpperCase() // 0x0131
   'K'.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
   ﬀ 	0xFB00 	FF
   ﬁ 	0xFB01 	FI
   ﬂ 	0xFB02 	FL
   ﬃ 	0xFB03 	FFI
   ﬄ 	0xFB04 	FFL
   ﬅ 	0xFB05 	ST
   ﬆ 	0xFB06 	ST
   K 	0x212A 	k

исправить +7 +/–

Лицензия: 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 +/–
Весьма древняя проблема. И она принципиально не лечится. - Если вы маппите одни символы в другие, вознимает множество проблем взаимодействия и неоднозначностей. Через которые системы могут того-этого. - А если не маппите, тогда можно спуфить ники, используя очень похожее отображение.

игнорирование участников | лог модерирования

Добавить комментарий

Текст: