Unicode Normalization

Reading time: 6 minutes

Dit is 'n opsomming van: https://appcheck-ng.com/unicode-normalization-vulnerabilities-the-special-k-polyglot/. Kyk daar vir verdere besonderhede (beelde geneem daar).

Verstaan van Unicode en Normalisering

Unicode normalisering is 'n proses wat verseker dat verskillende binêre verteenwoordigings van karakters gestandaardiseer word na dieselfde binêre waarde. Hierdie proses is van kardinale belang wanneer dit kom by stringe in programmering en dataverwerking. Die Unicode standaard definieer twee tipes karaktergelykheid:

1. Kanonieke Gelykheid: Karakters word as kanoniek gelyk beskou as hulle dieselfde voorkoms en betekenis het wanneer dit gedruk of vertoon word.
2. Compatibiliteitsgelykheid: 'n Swakker vorm van gelykheid waar karakters dieselfde abstrakte karakter kan verteenwoordig, maar anders vertoon kan word.

Daar is vier Unicode normalisering algoritmes: NFC, NFD, NFKC, en NFKD. Elke algoritme gebruik kanonieke en compatibiliteitsnormaliseringstegnieke op 'n ander manier. Vir 'n meer diepgaande begrip kan jy hierdie tegnieke op Unicode.org verken.

Sleutelpunte oor Unicode Kodering

Om Unicode kodering te verstaan is van kardinale belang, veral wanneer dit kom by interoperabiliteitskwessies tussen verskillende stelsels of tale. Hier is die hoofpunte:

• Kodepunte en Karakters: In Unicode word elke karakter of simbool 'n numeriese waarde toegeken wat bekend staan as 'n "kodepunt".
• Bytes Verteenwoordiging: Die kodepunt (of karakter) word deur een of meer bytes in geheue verteenwoordig. Byvoorbeeld, LATIN-1 karakters (algemeen in Engelssprekende lande) word met een byte verteenwoordig. egter, tale met 'n groter stel karakters benodig meer bytes vir verteenwoordiging.
• Kodering: Hierdie term verwys na hoe karakters in 'n reeks bytes omgeskakel word. UTF-8 is 'n algemene kodering standaard waar ASCII karakters met een byte verteenwoordig word, en tot vier bytes vir ander karakters.
• Verwerking van Data: Stelsels wat data verwerk moet bewus wees van die kodering wat gebruik word om die byte-stroom korrek in karakters om te skakel.
• Variantes van UTF: Benewens UTF-8, is daar ander koderingstandaarde soos UTF-16 (wat 'n minimum van 2 bytes gebruik, tot 4) en UTF-32 (wat 4 bytes vir alle karakters gebruik).

Dit is van kardinale belang om hierdie konsepte te verstaan om effektief te kan hanteer en potensiële probleme wat uit Unicode se kompleksiteit en sy verskillende koderingmetodes ontstaan, te verminder.

'n Voorbeeld van hoe Unicode twee verskillende bytes normaliseer wat dieselfde karakter verteenwoordig:

unicodedata.normalize("NFKD","chloe\u0301") == unicodedata.normalize("NFKD", "chlo\u00e9")

‘n Lys van Unicode ekwivalente karakters kan hier gevind word: https://appcheck-ng.com/wp-content/uploads/unicode_normalization.html en https://0xacb.com/normalization_table

Ontdekking

As jy 'n waarde in 'n webapp kan vind wat teruggegee word, kan jy probeer om ‘KELVIN TEKEN’ (U+0212A) te stuur wat normaliseer na "K" (jy kan dit as %e2%84%aa stuur). As 'n "K" teruggegee word, dan word daar 'n soort Unicode normalisering uitgevoer.

Ander voorbeeld: %F0%9D%95%83%E2%85%87%F0%9D%99%A4%F0%9D%93%83%E2%85%88%F0%9D%94%B0%F0%9D%94%A5%F0%9D%99%96%F0%9D%93%83 na unicode is Leonishan.

Kwetsbare Voorbeelde

SQL Injection filter omseiling

Stel jou voor 'n webblad wat die karakter ' gebruik om SQL navrae met die gebruiker se invoer te skep. Hierdie webblad, as 'n sekuriteitsmaatreël, verwyder alle voorkomste van die karakter ' uit die gebruiker se invoer, maar na daardie verwydering en voor die skepping van die navraag, normaliseer dit die gebruiker se invoer met Unicode.

Dan kan 'n kwaadwillige gebruiker 'n ander Unicode karakter wat ekwivalent is aan ' (0x27) soos %ef%bc%87 invoeg, wanneer die invoer genormaliseer word, word 'n enkele aanhalingsteken geskep en 'n SQLInjection kwesbaarheid verskyn:

Sommige interessante Unicode karakters

• o -- %e1%b4%bc
• r -- %e1%b4%bf
• 1 -- %c2%b9
• = -- %e2%81%bc
• / -- %ef%bc%8f
• --- %ef%b9%a3
• #-- %ef%b9%9f
• *-- %ef%b9%a1
• ' -- %ef%bc%87
• " -- %ef%bc%82
• | -- %ef%bd%9c

' or 1=1-- -
%ef%bc%87+%e1%b4%bc%e1%b4%bf+%c2%b9%e2%81%bc%c2%b9%ef%b9%a3%ef%b9%a3+%ef%b9%a3

" or 1=1-- -
%ef%bc%82+%e1%b4%bc%e1%b4%bf+%c2%b9%e2%81%bc%c2%b9%ef%b9%a3%ef%b9%a3+%ef%b9%a3

' || 1==1//
%ef%bc%87+%ef%bd%9c%ef%bd%9c+%c2%b9%e2%81%bc%e2%81%bc%c2%b9%ef%bc%8f%ef%bc%8f

" || 1==1//
%ef%bc%82+%ef%bd%9c%ef%bd%9c+%c2%b9%e2%81%bc%e2%81%bc%c2%b9%ef%bc%8f%ef%bc%8f

sqlmap-sjabloon

GitHub - carlospolop/sqlmap_to_unicode_template

XSS (Cross Site Scripting)

Jy kan een van die volgende karakters gebruik om die webapp te mislei en 'n XSS te benut:

Let op dat die eerste Unicode-karakter wat voorgestel word, gestuur kan word as: %e2%89%ae of as %u226e

Fuzzing Regexes

Wanneer die backend gebruikersinvoer met 'n regex nagaan, mag dit moontlik wees dat die invoer genormaliseer word vir die regex maar nie vir waar dit gebruik word nie. Byvoorbeeld, in 'n Open Redirect of SSRF mag die regex die gestuurde URL normaliseer maar dan dit soos dit is benader.

Die hulpmiddel recollapse **** laat jou toe om variasies van die invoer te genereer om die backend te fuzz. Vir meer inligting, kyk na die github en hierdie pos.

Verwysings

• https://labs.spotify.com/2013/06/18/creative-usernames/
• https://security.stackexchange.com/questions/48879/why-does-directory-traversal-attack-c0af-work
• https://jlajara.gitlab.io/posts/2020/02/19/Bypass_WAF_Unicode.html