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

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

Источник: opennet.ru