Unicode Normalization
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
This is a summary of: https://appcheck-ng.com/unicode-normalization-vulnerabilities-the-special-k-polyglot/. Check a look for further details (images taken form there).
Unicode normalisering is 'n proses wat verseker dat verskillende binêre voorstellings van karakters gestandaardiseer word na dieselfde binêre waarde. Hierdie proses is van kardinale belang in die hantering van stringe in programmering en dataverwerking. Die Unicode-standaard definieer twee tipes karaktergelykheid:
Canonical Equivalence: Karakters word as kanoniek gelyk beskou as hulle dieselfde voorkoms en betekenis het wanneer dit gedruk of vertoon word.
Compatibility Equivalence: 'n Swakker vorm van gelykheid waar karakters dieselfde abstrakte karakter kan voorstel, maar anders vertoon kan word.
Daar is vier Unicode normalisering algoritmes: NFC, NFD, NFKC, en NFKD. Elke algoritme gebruik kanonieke en kompatibiliteitsnormaliseringstegnieke op 'n ander manier. Vir 'n meer diepgaande begrip kan jy hierdie tegnieke op Unicode.org verken.
Om Unicode-kodering te verstaan, is van kardinale belang, veral wanneer dit kom by interoperabiliteitskwessies tussen verskillende stelsels of tale. Hier is die hoofpunte:
Code Points and Characters: In Unicode word elke karakter of simbool 'n numeriese waarde toegeken wat bekend staan as 'n "code point".
Bytes Representation: Die code point (of karakter) word deur een of meer bytes in geheue voorgestel. Byvoorbeeld, LATIN-1 karakters (algemeen in Engelssprekende lande) word met een byte voorgestel. egter, tale met 'n groter stel karakters benodig meer bytes vir voorstelling.
Encoding: Hierdie term verwys na hoe karakters in 'n reeks bytes omgeskakel word. UTF-8 is 'n algemene koderingstandaard waar ASCII karakters met een byte voorgestel word, en tot vier bytes vir ander karakters.
Processing Data: Stelsels wat data verwerk, moet bewus wees van die kodering wat gebruik word om die byte-stroom korrek in karakters om te skakel.
Variants of 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 voorstel:
‘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
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 stuur as %e2%84%aa). 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.
Stel jou voor 'n webblad wat die karakter ' gebruik om SQL navrae met die gebruiker se invoer te skep. Hierdie web, 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
Jy kan een van die volgende karakters gebruik om die webapp te mislei en 'n XSS te benut:
Let daarop dat die eerste Unicode-karakter wat voorgestel word, gestuur kan word as: %e2%89%ae of as %u226e
Wanneer die agterkant gebruikersinvoer met 'n regex nagaan, kan 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 kan die regex die gestuurde URL genormaliseer maar dan dit soos dit is benader.
Die hulpmiddel recollapse **** laat jou toe om variasies van die invoer te genereer om die agterkant te fuzz. Vir meer inligting, kyk na die github en hierdie pos.
Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
