Выкарыстанне падобных 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