Swahili - Ht
HackTricks Training Twitter Linkedin Sponsor

Unicode Normalization

Support HackTricks

WhiteIntel

WhiteIntel ni injini ya utafutaji inayotumiwa na dark-web ambayo inatoa kazi za bure kuangalia kama kampuni au wateja wake wamekuwa compromised na stealer malwares.

Lengo lao kuu la WhiteIntel ni kupambana na utekaji wa akaunti na mashambulizi ya ransomware yanayotokana na malware inayopora taarifa.

Unaweza kuangalia tovuti yao na kujaribu injini yao kwa bure kwenye:

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

Understanding Unicode and Normalization

Unicode normalization ni mchakato ambao unahakikisha uwakilishi tofauti wa kibinafsi wa wahusika unakuwa wa kiwango sawa. Mchakato huu ni muhimu katika kushughulikia nyuzi katika programu na usindikaji wa data. Kiwango cha Unicode kinabainisha aina mbili za usawa wa wahusika:

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

  2. Compatibility Equivalence: 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 ufahamu wa kina zaidi, unaweza kuchunguza mbinu hizi kwenye Unicode.org.

Key Points on Unicode Encoding

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 inatolewa 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 byte. 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:

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 kwenye chujio cha 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 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

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

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

Fuzzing Regexes

Wakati backend inafanya kuangalia ingizo la mtumiaji kwa regex, inaweza kuwa inawezekana kwamba ingizo linakuwa normalized kwa regex lakini siyo kwa mahali linapotumiwa. Kwa mfano, katika Open Redirect au SSRF regex inaweza kuwa normalizing the sent URL lakini kisha kuipata kama ilivyo.

Chombo recollapse **** kinaruhusu kuunda tofauti za ingizo ili kufuzz backend. Kwa maelezo zaidi angalia github na hii post.

References

WhiteIntel

WhiteIntel ni injini ya utafutaji inayotumiwa na dark-web ambayo inatoa kazi za bure kuangalia kama kampuni au wateja wake wamekuwa compromised na stealer malwares.

Lengo lao kuu la WhiteIntel ni kupambana na kuchukuliwa kwa akaunti na mashambulizi ya ransomware yanayotokana na malware ya kuiba taarifa.

Unaweza kuangalia tovuti yao na kujaribu injini yao bure kwenye:

Support HackTricks
PreviousUnicode InjectionNextUUID Insecurities

Last updated