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

"Использование похожих Unicode-символов для обхода аутентифик..."	+/–
Сообщение от opennews (??), 19-Дек-19, 14:59
GitHub оказался подвержен атаке, позволяющей захватить доступ к учётной записи через манипуляцию с Unicode-символами в email. Проблема связана с тем, что некоторые символы Unicode  при применении функций преобразования в нижний или верхний регистр транслируются в обычные символы, близкие по начертанию (когда несколько разных символов транслируются в один символ - например, турецкий символ "ı" и "i" при приведении в верхний регистр преобразуются в "I")... Подробнее: https://www.opennet.dev/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_val (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 | Индекс форумов | Темы | Пред. тема | След. тема