Unicode Normalization

Reading time: 6 minutes

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 unaohakikisha kwamba uwakilishi tofauti wa kibinafsi wa wahusika unastandariswa kuwa thamani moja ya kibinafsi. Mchakato huu ni muhimu katika kushughulikia nyuzi katika programu na usindikaji wa data. Kiwango cha Unicode kinaelezea 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 (wanaopatikana 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 (ikitumia angalau byte 2, hadi 4) na UTF-32 (ikitumia byte 4 kwa wahusika wote).

Ni muhimu kuelewa dhana hizi ili kushughulikia na kupunguza matatizo 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 ya Hatari

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 normalisation kwa 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:

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

GitHub - carlospolop/sqlmap_to_unicode_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 linapotumika. Kwa mfano, katika Open Redirect au SSRF regex inaweza kuwa normalizing the sent URL lakini kisha inaccess it as is.

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

Unicode Overflow

Kutoka kwenye blog, thamani ya juu ya byte ni 255, ikiwa server ina udhaifu, overflow inaweza kuandaliwa ili kutoa wahusika maalum na wasiotarajiwa wa ASCII. Kwa mfano, wahusika ifuatayo watahamasishwa kuwa A:

• 0x4e41
• 0x4f41
• 0x5041
• 0x5141

References

• 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
• https://portswigger.net/research/bypassing-character-blocklists-with-unicode-overflows