The OpenNET Project / Index page

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



"Использование похожих Unicode-символов для обхода аутентифик..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Использование похожих Unicode-символов для обхода аутентифик..."  +/
Сообщение от opennews (??), 19-Дек-19, 14:59 
GitHub оказался подвержен атаке, позволяющей захватить доступ к учётной записи через манипуляцию с Unicode-символами в email. Проблема связана с тем, что некоторые символы Unicode  при применении функций преобразования в нижний или верхний регистр транслируются в обычные символы, близкие по начертанию (когда несколько разных символов транслируются в один символ - например, турецкий символ "ı" и "i" при приведении в верхний регистр преобразуются в "I")...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=52047

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Использование похожих Unicode-символов для обхода аутентифик..."  +3 +/
Сообщение от helgi (??), 19-Дек-19, 14:59 
'ß'.toLowerCase() === 'SS'.toLowerCase()
false
'John@Gıthub.com'.toUpperCase() === 'John@Github.com'.toUpperCase();
true

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

Ответить | Правка | Наверх | Cообщить модератору

2. "Использование похожих Unicode-символов для обхода аутентифик..."  +/
Сообщение от svsd_valemail (ok), 19-Дек-19, 15:18 
Более того она нелепа =)
Ответить | Правка | Наверх | Cообщить модератору

4. "Использование похожих Unicode-символов для обхода аутентифик..."  +1 +/
Сообщение от Аноним (4), 20-Дек-19, 01:58 
toUpperCase в обоих случаях
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

3. "Использование похожих Unicode-символов для обхода аутентифик..."  +6 +/
Сообщение от Xasd (ok), 19-Дек-19, 21:45 
> Адрес проходил проверку так как преобразовывался в верхний регистр и
> совпадал с исходным адресом (mike@example.org ), но при отправке
> письма подставлялся как есть и код восстановления уходил по
> поддельному адресу (mıke@example.org

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

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

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

5. "Использование похожих Unicode-символов для обхода аутентифик..."  +1 +/
Сообщение от Аноним (-), 21-Дек-19, 17:24 
Весьма древняя проблема. И она принципиально не лечится.

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

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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