Använda liknande Unicode-tecken för att kringgå autentisering

GitHub visade sig vara är mottaglig för en attack som gör att du kan ta åtkomst till ett konto genom att manipulera Unicode-tecken i e-post. Problemet är att vissa Unicode-tecken, när man använder konverteringsfunktionerna för gemener eller versaler, översätts till vanliga tecken som liknar stilen (när flera olika tecken översätts till ett tecken - till exempel det turkiska tecknet "ı" och "i" " när den konverteras till versaler konverteras till "I").

Innan inloggningsparametrar kontrolleras i vissa tjänster och applikationer, konverteras användarens data först till versaler eller gemener och kontrolleras sedan i databasen. Om en tjänst tillåter användning av unicode-tecken i en inloggning eller e-post, kan en angripare använda liknande unicode-tecken för att utföra en attack som manipulerar kollisioner i Unicode Case Mapping Collisions.

'ß'.toUpperCase() == 'ss'.toUpperCase() // 0x0131
'K'.toLowerCase() == 'K'.toLowerCase() // 0x212A
'John@Gıthub.com'.toUpperCase() == '[e-postskyddad]'.toUpperCase()

Angripare på GitHub kunde genom formuläret för att återställa ett glömt lösenord, börja skicka en återställningskod till ett annat e-postmeddelande genom att i formuläret ange en adress som innehåller ett unicode-tecken som orsakar en kollision (till exempel istället för [e-postskyddad] e-post m angavsı[e-postskyddad]). Adressen klarade testet eftersom den konverterades till versaler och matchade den ursprungliga adressen ([e-postskyddad] ), men när brevet skickades ersattes det som det är och återställningskoden skickades till en falsk adress (mı[e-postskyddad]).

Några av tecken, orsakar kollisioner vid konvertering av register:

ß 0x00DF SS
jag 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

Källa: opennet.ru