Unicode Injection

Reading time: 6 minutes

Introduction

इस पर निर्भर करते हुए कि बैक-एंड/फ्रंट-एंड अजीब unicode वर्णों को प्राप्त करते समय कैसे व्यवहार करता है, एक हमलावर सुरक्षाओं को बायपास करने और मनमाने वर्णों को इंजेक्ट करने में सक्षम हो सकता है, जिन्हें इंजेक्शन कमजोरियों जैसे XSS या SQLi का दुरुपयोग करने के लिए उपयोग किया जा सकता है।

Unicode Normalization

Unicode सामान्यीकरण तब होता है जब unicode वर्णों को ascii वर्णों में सामान्यीकृत किया जाता है।

इस प्रकार की कमजोरी का एक सामान्य परिदृश्य तब होता है जब सिस्टम उपयोगकर्ता के इनपुट को किसी न किसी तरह संशोधित करता है जांचने के बाद। उदाहरण के लिए, कुछ भाषाओं में इनपुट को अपरकेस या लोअरकेस बनाने के लिए एक साधारण कॉल दिए गए इनपुट को सामान्यीकृत कर सकता है और unicode ASCII में परिवर्तित हो जाएगा, जिससे नए वर्ण उत्पन्न होंगे।
अधिक जानकारी के लिए देखें:

Unicode Normalization

\u to %

Unicode वर्ण आमतौर पर \u उपसर्ग के साथ प्रदर्शित होते हैं। उदाहरण के लिए, वर्ण 㱋 है \u3c4b(यहां जांचें). यदि एक बैकएंड \u उपसर्ग को % में परिवर्तित करता है, तो परिणामी स्ट्रिंग %3c4b होगी, जिसे URL डिकोड किया गया है: <4b। और, जैसा कि आप देख सकते हैं, एक < वर्ण इंजेक्ट किया गया है।
यदि बैकएंड कमजोर है तो आप इस तकनीक का उपयोग किसी भी प्रकार के वर्ण को इंजेक्ट करने के लिए कर सकते हैं।
आपको आवश्यक वर्ण खोजने के लिए https://unicode-explorer.com/ देखें।

यह कमजोरी वास्तव में एक शोधकर्ता द्वारा पाई गई एक कमजोरी से आती है, अधिक गहन व्याख्या के लिए देखें https://www.youtube.com/watch?v=aUsAHb0E7Cg

Emoji Injection

बैक-एंड कुछ अजीब तरीके से व्यवहार करते हैं जब वे इमोजी प्राप्त करते हैं। यही इस लेख में हुआ, जहां शोधकर्ता ने एक पेलोड जैसे: 💋img src=x onerror=alert(document.domain)//💛 के साथ XSS प्राप्त करने में सफल रहा।

इस मामले में, त्रुटि यह थी कि सर्वर ने दुर्भावनापूर्ण वर्णों को हटाने के बाद Windows-1252 से UTF-8 में UTF-8 स्ट्रिंग को परिवर्तित किया (बुनियादी रूप से इनपुट एन्कोडिंग और एन्कोडिंग रूपांतरण असंगत थे)। फिर यह एक उचित < नहीं देता, केवल एक अजीब unicode: ‹
``तो उन्होंने इस आउटपुट को लिया और अब UTF-8 से ASCII में फिर से परिवर्तित किया। इसने ‹ को < में सामान्यीकृत किया, यही कारण है कि यह प्रणाली पर एक्सप्लॉइट काम कर सका।
यह क्या हुआ:

<?php

$str = isset($_GET["str"]) ? htmlspecialchars($_GET["str"]) : "";

$str = iconv("Windows-1252", "UTF-8", $str);
$str = iconv("UTF-8", "ASCII//TRANSLIT", $str);

echo "String: " . $str;

Emoji lists:

• https://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv
• https://unicode.org/emoji/charts-14.0/full-emoji-list.html

Windows Best-Fit/Worst-fit

जैसा कि इस शानदार पोस्ट में बताया गया है, Windows में Best-Fit नामक एक विशेषता है जो unicode वर्णों को ASCII मोड में प्रदर्शित नहीं किया जा सकने वाले समान वर्णों से बदल देती है। इससे अप्रत्याशित व्यवहार हो सकता है जब बैकएंड एक विशिष्ट वर्ण की अपेक्षा करता है लेकिन उसे एक अलग वर्ण प्राप्त होता है।

https://worst.fit/mapping/ में सबसे अच्छे फिट वर्णों को ढूंढना संभव है।

चूंकि Windows आमतौर पर unicode स्ट्रिंग्स को ASCII स्ट्रिंग्स में निष्पादन के अंतिम भागों में परिवर्तित करता है (आमतौर पर "W" प्रत्यय वाले API से "A" प्रत्यय वाले API जैसे GetEnvironmentVariableA और GetEnvironmentVariableW में जाता है), यह हमलावरों को सुरक्षा को बायपास करने की अनुमति देगा, unicode वर्ण भेजकर जो अंततः ASCII वर्णों में परिवर्तित होंगे जो अप्रत्याशित क्रियाएँ करेंगे।

ब्लॉग पोस्ट में काले सूची के वर्णों का उपयोग करके कमजोरियों को बायपास करने के लिए प्रस्तावित विधियाँ हैं, “/“ (0x2F) के लिए मैप किए गए वर्णों का उपयोग करके पथ यात्रा का शोषण करना और “\“ (0x5C) के लिए मैप किए गए वर्णों का उपयोग करना या यहां तक कि PHP के escapeshellarg या Python के subprocess.run जैसे शेल एस्केप सुरक्षा को बायपास करना, यह उदाहरण के लिए पूर्ण चौड़ाई के डबल उद्धरण (U+FF02) का उपयोग करके किया गया था ताकि अंत में जो 1 तर्क जैसा दिखता था वह 2 तर्कों में परिवर्तित हो गया।

ध्यान दें कि किसी ऐप को कमजोर होने के लिए "W" Windows APIs का उपयोग करना आवश्यक है लेकिन अंततः "A" Windows API को कॉल करना आवश्यक है ताकि unicode स्ट्रिंग का "Best-fit" बनाया जा सके।

कई खोजी गई कमजोरियों को ठीक नहीं किया जाएगा क्योंकि लोग इस मुद्दे को ठीक करने के लिए सहमत नहीं हैं।