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

[tabac]

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() == 'John@Github.com'.toUpperCase()

В GitHub атакующий мог через форму восстановления забытого пароля инициировать отправку кода восстановления на другой email через указание в форме адреса, включающего unicode-символ, вызывающий коллизию (например, вместо mike@example.org указывался email mıke@example.org). Адрес проходил проверку так как преобразовывался в верхний регистр и совпадал с исходным адресом (mike@example.org ), но при отправке письма подставлялся как есть и код восстановления уходил по поддельному адресу (mıke@example.org).

Некоторые из символов, вызывающих коллизии при преобразовании регистра:

    ß     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

 

[spectrum]

Гениально !