Unicode Normalization
यह एक सारांश है: https://appcheck-ng.com/unicode-normalization-vulnerabilities-the-special-k-polyglot/. आगे की जानकारी के लिए देखें (छवियाँ वहाँ से ली गई हैं)।
Understanding Unicode and Normalization
Unicode normalization एक प्रक्रिया है जो सुनिश्चित करती है कि वर्णों के विभिन्न बाइनरी प्रतिनिधित्व को एक ही बाइनरी मान में मानकीकृत किया जाए। यह प्रक्रिया प्रोग्रामिंग और डेटा प्रोसेसिंग में स्ट्रिंग्स के साथ काम करते समय महत्वपूर्ण है। Unicode मानक दो प्रकार की वर्ण समकक्षता को परिभाषित करता है:
Canonical Equivalence: वर्णों को कैनोनिकल रूप से समकक्ष माना जाता है यदि उनका प्रिंट या प्रदर्शित होने पर एक ही रूप और अर्थ होता है।
Compatibility Equivalence: समकक्षता का एक कमजोर रूप जहाँ वर्ण एक ही अमूर्त वर्ण का प्रतिनिधित्व कर सकते हैं लेकिन अलग-अलग तरीके से प्रदर्शित हो सकते हैं।
चार Unicode normalization एल्गोरिदम हैं: NFC, NFD, NFKC, और NFKD। प्रत्येक एल्गोरिदम कैनोनिकल और संगतता मानकीकरण तकनीकों का उपयोग अलग-अलग तरीके से करता है। अधिक गहन समझ के लिए, आप इन तकनीकों का अन्वेषण कर सकते हैं Unicode.org पर।
Key Points on Unicode Encoding
Unicode एन्कोडिंग को समझना महत्वपूर्ण है, विशेष रूप से विभिन्न प्रणालियों या भाषाओं के बीच इंटरऑपरेबिलिटी मुद्दों से निपटने के समय। यहाँ मुख्य बिंदु हैं:
कोड पॉइंट और वर्ण: Unicode में, प्रत्येक वर्ण या प्रतीक को एक संख्यात्मक मान सौंपा जाता है जिसे "कोड पॉइंट" कहा जाता है।
बाइट्स प्रतिनिधित्व: कोड पॉइंट (या वर्ण) को मेमोरी में एक या अधिक बाइट्स द्वारा दर्शाया जाता है। उदाहरण के लिए, LATIN-1 वर्ण (अंग्रेजी बोलने वाले देशों में सामान्य) को एक बाइट का उपयोग करके दर्शाया जाता है। हालाँकि, जिन भाषाओं में वर्णों का बड़ा सेट होता है, उन्हें प्रतिनिधित्व के लिए अधिक बाइट्स की आवश्यकता होती है।
एन्कोडिंग: यह शब्द वर्णों को बाइट्स की एक श्रृंखला में परिवर्तित करने के तरीके को संदर्भित करता है। UTF-8 एक प्रचलित एन्कोडिंग मानक है जहाँ ASCII वर्णों को एक बाइट का उपयोग करके दर्शाया जाता है, और अन्य वर्णों के लिए चार बाइट्स तक।
डेटा प्रोसेसिंग: डेटा प्रोसेसिंग करने वाली प्रणालियों को एन्कोडिंग के बारे में जागरूक होना चाहिए ताकि बाइट स्ट्रीम को सही तरीके से वर्णों में परिवर्तित किया जा सके।
UTF के रूप: UTF-8 के अलावा, अन्य एन्कोडिंग मानक हैं जैसे UTF-16 (कम से कम 2 बाइट्स का उपयोग करते हुए, 4 तक) और UTF-32 (सभी वर्णों के लिए 4 बाइट्स का उपयोग करते हुए)।
इन अवधारणाओं को समझना महत्वपूर्ण है ताकि Unicode की जटिलता और इसके विभिन्न एन्कोडिंग विधियों से उत्पन्न संभावित मुद्दों को प्रभावी ढंग से संभाला और कम किया जा सके।
Unicode के दो अलग-अलग बाइट्स को एक ही वर्ण का प्रतिनिधित्व करने के तरीके का एक उदाहरण:
एक सूची Unicode समकक्ष वर्णों की यहाँ पाई जा सकती है: https://appcheck-ng.com/wp-content/uploads/unicode_normalization.html और https://0xacb.com/normalization_table
खोज
यदि आप एक वेब ऐप के अंदर एक ऐसा मान ढूंढ सकते हैं जो वापस इको हो रहा है, तो आप ‘KELVIN SIGN’ (U+0212A) भेजने की कोशिश कर सकते हैं जो "K" में सामान्यीकृत होता है (आप इसे %e2%84%aa के रूप में भेज सकते हैं)। यदि "K" वापस इको होता है, तो कुछ प्रकार की Unicode सामान्यीकरण की प्रक्रिया की जा रही है।
अन्य उदाहरण: %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 के बाद unicode Leonishan है।
कमजोर उदाहरण
SQL Injection फ़िल्टर बायपास
कल्पना करें कि एक वेब पृष्ठ उपयोगकर्ता इनपुट के साथ SQL क्वेरी बनाने के लिए वर्ण ' का उपयोग कर रहा है। यह वेब, एक सुरक्षा उपाय के रूप में, उपयोगकर्ता इनपुट से वर्ण ' के सभी उदाहरणों को हटाता है, लेकिन उस हटाने के बाद और क्वेरी बनाने से पहले, यह उपयोगकर्ता के इनपुट को Unicode का उपयोग करके सामान्यीकृत करता है।
फिर, एक दुर्भावनापूर्ण उपयोगकर्ता एक अलग Unicode वर्ण डाल सकता है जो ' (0x27) के समकक्ष है जैसे %ef%bc%87, जब इनपुट सामान्यीकृत होता है, तो एक सिंगल कोट बनाया जाता है और एक SQLInjection भेद्यता प्रकट होती है:
कुछ दिलचस्प Unicode वर्ण
o-- %e1%b4%bcr-- %e1%b4%bf1-- %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
sqlmap 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 और इस पोस्ट की जांच करें।
References
Last updated
