Unicode Normalization

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Hii ni muhtasari wa: https://appcheck-ng.com/unicode-normalization-vulnerabilities-the-special-k-polyglot/. Angalia kwa maelezo zaidi (picha zimechukuliwa kutoka hapo).

Kuelewa Unicode na Normalization

Unicode normalization ni mchakato unaohakikisha kwamba uwakilishi tofauti wa binary wa wahusika unakuwa wa kiwango sawa na thamani ya binary. Mchakato huu ni muhimu katika kushughulikia nyuzi katika programu na usindikaji wa data. Kiwango cha Unicode kinaelezea aina mbili za usawa wa wahusika:

  1. Usawa wa Canonical: Wahusika wanachukuliwa kuwa sawa kikanuni ikiwa wana muonekano na maana sawa wanapochapishwa au kuonyeshwa.

  2. Usawa wa Ulinganifu: Aina dhaifu ya usawa ambapo wahusika wanaweza kuwakilisha wahusika sawa wa kiabstrakti 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 kuelewa zaidi, unaweza kuchunguza mbinu hizi kwenye Unicode.org.

Vidokezo Muhimu Kuhusu Unicode Encoding

Kuelewa Unicode encoding ni muhimu, hasa unaposhughulikia masuala ya ushirikiano kati ya mifumo au lugha tofauti. Hapa kuna vidokezo vikuu:

  • Pointi za Msimbo na Wahusika: Katika Unicode, kila wahusika au alama inapewa thamani ya nambari inayojulikana kama "code point".

  • Uwaki wa Bytes: Pointi ya msimbo (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.

  • Usindikaji wa Data: Mifumo inayosindika data inapaswa kuwa na ufahamu wa encoding inayotumika ili kubadilisha mfululizo wa byte kuwa wahusika kwa usahihi.

  • Tofauti za 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:

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

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

Kugundua

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.

Mifano Inayoweza Kuathiriwa

Kupita mfilizo wa SQL Injection

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 normalised, nukta moja inaundwa na SQLInjection vulnerability inaonekana:

https://appcheck-ng.com/unicode-normalization-vulnerabilities-the-special-k-polyglot/

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

' 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 template

XSS (Cross Site Scripting)

Unaweza kutumia moja ya wahusika ifuatayo kudanganya webapp na kutumia XSS:

https://appcheck-ng.com/unicode-normalization-vulnerabilities-the-special-k-polyglot/

Kumbuka kwamba kwa mfano wahusika wa kwanza wa Unicode wanaweza kutumwa kama: %e2%89%ae au kama %u226e

https://appcheck-ng.com/unicode-normalization-vulnerabilities-the-special-k-polyglot/

Fuzzing Regexes

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.

References

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Last updated