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 normalization ni mchakato ambao unahakikisha uwakilishi tofauti wa binary wa wahusika unakuwa wa kiwango sawa na thamani ya binary sawa. Mchakato huu ni muhimu katika kushughulikia nyuzi katika programu na usindikaji wa data. Kiwango cha Unicode kinaelezea aina mbili za usawa wa wahusika:
Canonical Equivalence: Wahusika wanachukuliwa kuwa sawa kikanuni ikiwa wana muonekano na maana sawa wanapochapishwa au kuonyeshwa.
Compatibility Equivalence: Aina dhaifu ya usawa ambapo wahusika wanaweza kuwakilisha wahusika sawa wa dhana lakini wanaweza kuonyeshwa tofauti.
Kuna algorithms nne za Unicode normalization: NFC, NFD, NFKC, na NFKD. Kila algorithm inatumia mbinu za canonical na compatibility normalization kwa njia tofauti. Kwa ufahamu wa kina zaidi, unaweza kuchunguza mbinu hizi kwenye Unicode.org.
Kuelewa encoding ya Unicode ni muhimu, hasa unaposhughulikia masuala ya ushirikiano kati ya mifumo au lugha tofauti. Hapa kuna pointi kuu:
Code Points and Characters: Katika Unicode, kila wahusika au alama inapewa thamani ya nambari inayojulikana kama "code point".
Bytes Representation: Code point (au wahusika) inawakilishwa na byte moja au zaidi katika kumbukumbu. Kwa mfano, wahusika wa LATIN-1 (wanaotumika sana katika nchi zinazozungumza Kiingereza) wanawakilishwa kwa kutumia byte moja. Hata hivyo, lugha zenye seti kubwa ya wahusika zinahitaji byte zaidi kwa uwakilishi.
Encoding: Neno hili linarejelea jinsi wahusika wanavyobadilishwa kuwa mfululizo wa bytes. UTF-8 ni kiwango maarufu cha encoding ambapo wahusika wa ASCII wanawakilishwa kwa kutumia byte moja, na hadi byte nne kwa wahusika wengine.
Processing Data: Mifumo inayosindika data inapaswa kuwa na ufahamu wa encoding inayotumika ili kubadilisha mfululizo wa byte kuwa wahusika kwa usahihi.
Variants of UTF: Mbali na UTF-8, kuna viwango vingine vya encoding kama UTF-16 (inayotumia angalau byte 2, hadi 4) na UTF-32 (inayotumia byte 4 kwa wahusika wote).
Ni muhimu kuelewa dhana hizi ili kushughulikia na kupunguza masuala yanayoweza kutokea kutokana na ugumu wa Unicode na mbinu zake mbalimbali za encoding.
Mfano wa jinsi Unicode inavyonormalize byte mbili tofauti zinazowakilisha wahusika sawa:
Orodha ya wahusika sawa wa Unicode inaweza kupatikana hapa: https://appcheck-ng.com/wp-content/uploads/unicode_normalization.html na https://0xacb.com/normalization_table
Ikiwa unaweza kupata ndani ya webapp thamani inayorejelewa, unaweza kujaribu kutuma ‘KELVIN SIGN’ (U+0212A) ambayo inarejelewa kama "K" (unaweza kuituma kama %e2%84%aa
). Ikiwa "K" inarejelewa, basi, aina fulani ya Unicode normalisation inafanywa.
Mfano mwingine: %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
baada ya unicode ni Leonishan
.
Fikiria ukurasa wa wavuti unaotumia wahusika '
kuunda maswali ya SQL na ingizo la mtumiaji. Wavuti hii, kama hatua ya usalama, inafuta matukio yote ya wahusika '
kutoka kwa ingizo la mtumiaji, lakini baada ya kufutwa na kabla ya kuunda swali, inafanya normalises kutumia Unicode ingizo la mtumiaji.
Basi, mtumiaji mbaya anaweza kuingiza wahusika tofauti wa Unicode sawa na ' (0x27)
kama %ef%bc%87
, wakati ingizo linapofanywa kuwa la kawaida, nukta moja inaundwa na SQLInjection vulnerability inaonekana:
Wahusika wa Unicode wa kuvutia
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
Unaweza kutumia moja ya wahusika ifuatayo kudanganya webapp na kutumia XSS:
Kumbuka kwamba kwa mfano wahusika wa kwanza wa Unicode wanaweza kutumwa kama: %e2%89%ae
au kama %u226e
Wakati backend inafanya kuangalia ingizo la mtumiaji kwa regex, inaweza kuwa inawezekana kwamba ingizo linakuwa normalized kwa regex lakini siyo kwa mahali linapotumika. Kwa mfano, katika Open Redirect au SSRF regex inaweza kuwa normalizing the sent URL lakini kisha inapata kama ilivyo.
Chombo recollapse **** kinaruhusu kuunda tofauti za ingizo ili kufuzz backend. Kwa maelezo zaidi angalia github na hii post.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)