Unicode Normalization

Reading time: 8 minutes

यह एक सारांश है: https://appcheck-ng.com/unicode-normalization-vulnerabilities-the-special-k-polyglot/. आगे की जानकारी के लिए देखें (छवियाँ वहाँ से ली गई हैं)।

Understanding Unicode and Normalization

Unicode normalization एक प्रक्रिया है जो सुनिश्चित करती है कि वर्णों के विभिन्न बाइनरी प्रतिनिधित्व को एक ही बाइनरी मान में मानकीकृत किया जाए। यह प्रक्रिया प्रोग्रामिंग और डेटा प्रोसेसिंग में स्ट्रिंग्स के साथ काम करते समय महत्वपूर्ण है। Unicode मानक वर्ण समकक्षता के दो प्रकारों को परिभाषित करता है:

1. Canonical Equivalence: वर्णों को कैनोनिकल रूप से समकक्ष माना जाता है यदि उनका प्रिंट या डिस्प्ले पर एक ही रूप और अर्थ होता है।
2. Compatibility Equivalence: समकक्षता का एक कमजोर रूप जहाँ वर्ण एक ही अमूर्त वर्ण का प्रतिनिधित्व कर सकते हैं लेकिन अलग-अलग तरीके से प्रदर्शित हो सकते हैं।

चार Unicode normalization algorithms हैं: NFC, NFD, NFKC, और NFKD। प्रत्येक एल्गोरिदम कैनोनिकल और संगतता मानकीकरण तकनीकों का उपयोग अलग-अलग तरीके से करता है। अधिक गहन समझ के लिए, आप इन तकनीकों का अन्वेषण कर सकते हैं Unicode.org पर।

Key Points on Unicode Encoding

Unicode एन्कोडिंग को समझना महत्वपूर्ण है, विशेष रूप से विभिन्न सिस्टमों या भाषाओं के बीच इंटरऑपरेबिलिटी मुद्दों से निपटने के समय। यहाँ मुख्य बिंदु हैं:

• Code Points and Characters: Unicode में, प्रत्येक वर्ण या प्रतीक को एक संख्यात्मक मान सौंपा जाता है जिसे "कोड पॉइंट" कहा जाता है।
• Bytes Representation: कोड पॉइंट (या वर्ण) को मेमोरी में एक या अधिक बाइट्स द्वारा प्रदर्शित किया जाता है। उदाहरण के लिए, LATIN-1 वर्ण (अंग्रेजी बोलने वाले देशों में सामान्य) एक बाइट का उपयोग करके प्रदर्शित होते हैं। हालाँकि, जिन भाषाओं में वर्णों का बड़ा सेट होता है, उन्हें प्रतिनिधित्व के लिए अधिक बाइट्स की आवश्यकता होती है।
• Encoding: यह शब्द वर्णों को बाइट्स की एक श्रृंखला में परिवर्तित करने के तरीके को संदर्भित करता है। UTF-8 एक प्रचलित एन्कोडिंग मानक है जहाँ ASCII वर्णों को एक बाइट का उपयोग करके प्रदर्शित किया जाता है, और अन्य वर्णों के लिए चार बाइट्स तक।
• Processing Data: डेटा प्रोसेसिंग करने वाले सिस्टम को एन्कोडिंग के बारे में जागरूक होना चाहिए ताकि बाइट स्ट्रीम को सही तरीके से वर्णों में परिवर्तित किया जा सके।
• Variants of UTF: UTF-8 के अलावा, अन्य एन्कोडिंग मानक हैं जैसे UTF-16 (जो न्यूनतम 2 बाइट्स का उपयोग करता है, अधिकतम 4) और UTF-32 (जो सभी वर्णों के लिए 4 बाइट्स का उपयोग करता है)।

इन अवधारणाओं को समझना महत्वपूर्ण है ताकि Unicode की जटिलता और इसके विभिन्न एन्कोडिंग तरीकों से उत्पन्न संभावित मुद्दों को प्रभावी ढंग से संभाला और कम किया जा सके।

Unicode के दो अलग-अलग बाइट्स को एक ही वर्ण का प्रतिनिधित्व करने के तरीके का एक उदाहरण:

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

यहाँ यूनिकोड समकक्ष वर्णों की एक सूची मिल सकती है: https://appcheck-ng.com/wp-content/uploads/unicode_normalization.html और https://0xacb.com/normalization_table

खोज करना

यदि आप किसी वेब ऐप में एक ऐसा मान ढूंढ सकते हैं जो वापस इको किया जा रहा है, तो आप ‘KELVIN SIGN’ (U+0212A) भेजने की कोशिश कर सकते हैं जो "K" में नॉर्मलाइज होता है (आप इसे %e2%84%aa के रूप में भेज सकते हैं)। यदि "K" वापस इको किया जाता है, तो कुछ प्रकार की यूनिकोड नॉर्मलाइजेशन की जा रही है।

अन्य उदाहरण: %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 के बाद यूनिकोड Leonishan है।

कमजोर उदाहरण

SQL Injection फ़िल्टर बायपास

कल्पना करें कि एक वेब पृष्ठ उपयोगकर्ता इनपुट के साथ SQL क्वेरी बनाने के लिए वर्ण ' का उपयोग कर रहा है। यह वेब, एक सुरक्षा उपाय के रूप में, उपयोगकर्ता इनपुट से वर्ण ' के सभी उदाहरणों को हटाता है, लेकिन उस हटाने के बाद और क्वेरी बनाने से पहले, यह उपयोगकर्ता के इनपुट को यूनिकोड का उपयोग करके नॉर्मलाइज करता है।

फिर, एक दुर्भावनापूर्ण उपयोगकर्ता एक अलग यूनिकोड वर्ण डाल सकता है जो ' (0x27) के समकक्ष है जैसे %ef%bc%87, जब इनपुट नॉर्मलाइज होता है, तो एक सिंगल कोट बनाया जाता है और एक SQLInjection vulnerability प्रकट होती है:

कुछ दिलचस्प यूनिकोड वर्ण

• 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)

आप निम्नलिखित में से किसी एक चरित्र का उपयोग करके वेब ऐप को धोखा दे सकते हैं और XSS का शोषण कर सकते हैं:

ध्यान दें कि उदाहरण के लिए, पहले Unicode चरित्र को इस प्रकार भेजा जा सकता है: %e2%89%ae या %u226e

Fuzzing Regexes

जब बैकएंड उपयोगकर्ता इनपुट को regex के साथ जांच रहा है, तो यह संभव है कि इनपुट को regex के लिए normalize किया जा रहा हो लेकिन जहां इसका उपयोग किया जा रहा है वहां नहीं। उदाहरण के लिए, एक Open Redirect या SSRF में regex भेजे गए URL को normalize कर सकता है लेकिन फिर इसे जैसा है वैसा ही एक्सेस कर सकता है।

उपकरण recollapse इनपुट के विभिन्न रूपों को उत्पन्न करने की अनुमति देता है ताकि बैकएंड को fuzz किया जा सके। अधिक जानकारी के लिए github और इस पोस्ट की जांच करें।

Unicode Overflow

इस ब्लॉग से, एक बाइट का अधिकतम मान 255 है, यदि सर्वर कमजोर है, तो एक ओवरफ्लो को एक विशिष्ट और अप्रत्याशित ASCII चरित्र उत्पन्न करने के लिए तैयार किया जा सकता है। उदाहरण के लिए, निम्नलिखित चरित्र 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