Використання схожих 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() == '[захищено електронною поштою]'.toUpperCase()

У GitHub атакуючий міг через форму відновлення забутого пароля ініціювати відправку коду відновлення на інший email через вказівку у формі адреси, що включає unicode-символ, що викликає колізію (наприклад, замість [захищено електронною поштою] вказувався email mı[захищено електронною поштою]). Адреса проходив перевірку оскільки перетворювався у верхній регістр і збігався з вихідною адресою ([захищено електронною поштою] ), але при відправці листа підставлявся як є і код відновлення йшов за підробленою адресою (mı[захищено електронною поштою]).

Деякі з символів, що викликають колізії при перетворенні регістру:

ß 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