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

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

• Использование похожих Unicode-символов для обхода аутентифик...,helgi, 14:59 , 19-Дек-19
  • Использование похожих Unicode-символов для обхода аутентифик...,svsd_val, 15:18 , 19-Дек-19
  • Использование похожих Unicode-символов для обхода аутентифик...,Аноним, 01:58 , 20-Дек-19
• Использование похожих Unicode-символов для обхода аутентифик...,Xasd, 21:45 , 19-Дек-19
• Использование похожих Unicode-символов для обхода аутентифик...,Аноним, 17:24 , 21-Дек-19

'ß'.toLowerCase() === 'SS'.toLowerCase()
false
'John@Gıthub.com'.toUpperCase() === 'John@Github.com'.toUpperCase();
true

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

Более того она нелепа =)

toUpperCase в обоих случаях

> Адрес проходил проверку так как преобразовывался в верхний регистр и
> совпадал с исходным адресом (mike@example.org ), но при отправке
> письма подставлялся как есть и код восстановления уходил по
> поддельному адресу (mıke@example.org

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

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

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

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

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

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

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

Весьма древняя проблема. И она принципиально не лечится.

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