डेवलपर टूल · URL एनकोडर और डिकोडर
URL एन्कोडिंग स्वच्छताकरण नहीं है: डिकोड किए गए मापदंडों को अभी भी भागने की आवश्यकता है
· यह क्यों मायने रखती है
URL एन्कोडिंग सुरक्षा xss
प्रतिशत-एन्कोडिंग URL संरचना की सुरक्षा करती है, न कि आपके HTML, SQL या शेल की। यह पोस्ट बताती है कि सही ढंग से एन्कोड किया गया मान डीकोड होते ही फिर से खतरनाक क्यों हो जाता है, और कौन सा भाग कहां से निकल रहा है।
क्यों URL एन्कोडिंग अकेले XSS हमलों को नहीं रोक सकती
एक "सुरक्षित" पैरामीटर स्क्रिप्ट चला सकता है यदि ट्रांसमिशन के लिए एन्कोड किया गया हो लेकिन रेंडरिंग से पहले डिकोड किया गया हो। XSS पेलोड को img टैग की तरह मानें जिसमें ऑनररर हैंडलर प्रतिशत-एन्कोडेड %3Cimg%20src%3Dx%20onerror%3Dalert%281%29%3E है। यदि यह URL में यात्रा करता है और HTML में डालने से पहले एप्लिकेशन कोड द्वारा डिकोड किया जाता है, तो ब्राउज़र मूल मार्कअप देखता है और हैंडलर निष्पादित करता है। प्रतिशत-एन्कोडिंग प्रतिनिधित्व परत है; अंतर्निहित ख़तरा नहीं बदलता.
पेलोड केवल ट्रांसमिशन के दौरान सुरक्षित होता है, जब यह एन्कोडेड स्ट्रिंग होता है जिसका HTTP या URL पार्सर के लिए कोई विशेष अर्थ नहीं होता है। जैसे ही यह डिकोड होता है, यह फिर से खतरनाक हो जाता है क्योंकि यह अपने मूल रूप में वापस आ जाता है। प्रत्येक डाउनस्ट्रीम संदर्भ को डेटा का उपयोग करने के तरीके के अनुरूप अपने स्वयं के भागने के नियमों को लागू करना होगा। URL एन्कोडिंग HTML एस्केपिंग, SQL पैरामीटराइजेशन या शेल तर्क हैंडलिंग का विकल्प नहीं है।
प्रतिशत-एन्कोडिंग किस लिए है - सीमांकक को तार पर स्पष्ट रखना, इससे अधिक कुछ नहीं
प्रतिशत-एन्कोडिंग URL संरचना की सटीक सुरक्षा करती है। एम्परसेंड क्वेरी स्ट्रिंग सिंटैक्स का हिस्सा बना हुआ है, इसे सीमांकक के रूप में दोबारा व्याख्या नहीं किया गया है। स्लैश पथ विभाजक नहीं बनता. प्रश्न चिह्न खंड प्रारंभ नहीं होता. आरक्षित वर्णों को %XX के रूप में एन्कोड करके, पार्सर उन्हें डेटा के रूप में मानता है, सिंटैक्स के रूप में नहीं। यह एक काम के लिए काम करता है: URL संरचना को तार पर स्पष्ट रखना।
डिकोडिंग उस एकतरफा रास्ते को बिल्कुल उलट देती है। पुनर्स्थापित बाइट्स बिल्कुल वही हैं जो एन्कोड किया गया था, न कुछ अधिक और न कुछ कम। HTML-खतरनाक स्ट्रिंग खतरनाक रहती है, SQL-इंजेक्शन वेक्टर खतरनाक रहता है, और शेल कमांड खतरनाक रहता है। प्रतिशत-एन्कोडिंग इनपुट सत्यापन नहीं है, स्वच्छता नहीं है और सुरक्षा सीमा नहीं है। यह केवल प्रतिनिधित्व प्रारूप है.
डिकोडिंग मूल बाइट्स को पुनर्स्थापित करता है - इसलिए प्रत्येक डाउनस्ट्रीम संदर्भ कच्चे मूल्य को फिर से देखता है
संदर्भ-विशिष्ट पलायन वह जगह है जहां वास्तविक सुरक्षा वास्तव में रहती है। HTML संदर्भ को इकाइयों की आवश्यकता होती है: कम-से-कम हो जाता है <, अधिक से अधिक हो जाता है >, उद्धरण बन जाते हैं ", एम्परसेंड & बन जाता है। SQL संदर्भ को डेटा से संरचना को अलग करने वाले पैरामीटरयुक्त प्रश्नों की आवश्यकता होती है, जो हमलावर को टूटने से रोकते हैं। शेल संदर्भ को शब्द विभाजन और ग्लोबिंग से पूरी तरह से बचने के लिए तर्क सरणियों की आवश्यकता होती है।
प्रत्येक संदर्भ में अलग-अलग खतरनाक पात्र और अलग-अलग भागने के नियम होते हैं। HTML इकाई SQL क्वेरी में हानिरहित है लेकिन वहां सुरक्षा के लिए बेकार है। बैकस्लैश कुछ डेटाबेस में SQL इंजेक्शन को रोकता है लेकिन अन्य को नहीं। शैल का बचना उद्धरण शैली पर निर्भर करता है। डेटा को प्रबंधित करने का तरीका चुनने से पहले डेवलपर को गंतव्य को समझना चाहिए।
संदर्भ-विशिष्ट एस्केपिंग - मार्कअप के लिए HTML इकाइयां, SQL के लिए पैरामीटरयुक्त क्वेरीज़, शेल्स के लिए तर्क सारणी
कार्यान्वित उदाहरण: लिंक से लॉग तक पेज पर निम्नलिखित पेलोड से पता चलता है कि एन्कोडिंग और एस्केपिंग कहाँ होनी चाहिए। लिंक में क्वेरी पैरामीटर के रूप में एन्कोडेड XSS पेलोड शामिल है। सर्वर इसे अभी भी HTTP अनुरोध निकाय में एन्कोडेड प्राप्त करता है। एप्लिकेशन क्वेरी पैरामीटर को पेज में प्रदर्शित करने के लिए डीकोड करता है। आउटपुट से बचने के बिना, ब्राउज़र पेलोड को HTML के रूप में प्रस्तुत करता है और इसे निष्पादित करता है।
यदि समान पैरामीटर फ़ाइल में लॉग किया गया है, तो लॉग प्रविष्टि में स्पष्ट रूप से डीकोडेड पेलोड शामिल है। दूसरा एप्लिकेशन लॉग को पढ़ता है, फिर से डीकोड करता है, उसे बिना भागे HTML पेज में डाल देता है। पेलोड दूसरी बार निष्पादित होता है। प्रत्येक चरण पर, संदर्भ ने निर्धारित किया कि क्या सुरक्षित था। URL डिकोडिंग सुरक्षित थी. फ़ाइल भंडारण सुरक्षित था. लेकिन HTML बिना भागे आउटपुट घातक था।
कार्यान्वित उदाहरण: लिंक से लॉग तक पेज पर एक पेलोड का अनुसरण करना - जहां इसे एन्कोड किया गया है, जहां इसे डिकोड किया गया है, जहां इसे एस्केप किया जाना चाहिए
फ़िल्टर-चोरी टूल के रूप में एन्कोडिंग से पता चलता है कि क्यों हमलावर डबल-एनकोड करते हैं और हेक्स केस को महत्वपूर्ण रूप से मिलाते हैं। यदि फ़ायरवॉल img टैग की तलाश करता है, तो हमलावर %3Cimg भेजता है और उम्मीद करता है कि एप्लिकेशन एक बार डीकोड हो जाए लेकिन फ़ायरवॉल ऐसा नहीं करता है। यदि सत्यापन %3Cimg को अस्वीकार करता है लेकिन भिन्न मामले की अनुमति देता है, तो समान बाइट्स समान पेलोड में डिकोड होते हैं। एन्कोडेड इनपुट से मेल खाने वाले पैटर्न के आधार पर सुरक्षा भंगुर है।
डिकोडिंग बिल्कुल सटीक और पूर्वानुमानित होनी चाहिए। कैनोनिकल फॉर्म (लोअरकेस हेक्स, ज्ञात एन्कोडिंग) सुसंगत नीति की अनुमति देता है लेकिन अंतर्निहित समस्या का समाधान नहीं करता है। एकमात्र विश्वसनीय तरीका यह है कि जहां आवश्यक हो वहां डिकोडिंग की अनुमति दी जाए और उपयोग से तुरंत पहले संदर्भ-विशिष्ट आउटपुट को लागू किया जाए। डिकोडिंग कभी भी सुरक्षित नहीं होती; केवल प्रसारण के लिए आवश्यक है।
फ़िल्टर-चोरी टूल के रूप में एन्कोडिंग - हमलावर हेक्स केस को डबल-एनकोड और मिक्स क्यों करते हैं, और डिकोडिंग सटीक क्यों होनी चाहिए
पूर्ण XSS रक्षा के लिए डेटा प्रवाह को पूरी तरह से समझने की आवश्यकता होती है, यह प्रत्येक चरण में जिन संदर्भों से गुजरता है, प्रत्येक संदर्भ से बचने के लिए क्या चाहिए। URL एन्कोडिंग एक छोटा सा टुकड़ा है: केवल ट्रांसमिशन के दौरान संरचना को संरक्षित करता है। लेकिन एक टुकड़ा कभी भी अपने आप में रक्षा नहीं है। कई डेवलपर्स एन्कोडिंग को सैनिटाइजेशन के साथ जोड़ते हैं क्योंकि दोनों में पात्रों को बदलना शामिल है, लेकिन पूरी तरह से अलग-अलग महत्वपूर्ण कार्य करते हैं।
वेब एप्लिकेशन फ़ायरवॉल अनुरोध पेलोड में पैटर्न का पता लगा सकता है, लेकिन एन्कोडिंग सरल पैटर्न मिलान तकनीकों से आसानी से बच जाती है। WAF ट्यूनिंग जटिल है और URL एन्कोडिंग से परे है। विश्वसनीय सुरक्षा एप्लिकेशन कोड में आउटपुट एस्केपिंग है, जिसे इनपुट सत्यापन के साथ जोड़ा जाता है, जहां यह आपके विशिष्ट संदर्भ और आवश्यकताओं के लिए समझ में आता है।
इसमें क्या शामिल नहीं है - एक पूर्ण XSS रक्षा गाइड या वेब एप्लिकेशन फ़ायरवॉल ट्यूनिंग
पूर्ण XSS रक्षा के लिए डेटा प्रवाह को पूरी तरह से समझने की आवश्यकता होती है, यह प्रत्येक चरण में जिन संदर्भों से गुजरता है, उन्हें पूरे एप्लिकेशन में प्रत्येक संदर्भ से बचने की क्या आवश्यकता है। URL एन्कोडिंग एक छोटा सा टुकड़ा है: केवल ट्रांसमिशन के दौरान संरचना को संरक्षित करता है। लेकिन एक टुकड़ा कभी भी अपने आप में रक्षा नहीं है। कई डेवलपर्स एन्कोडिंग को सैनिटाइजेशन के साथ जोड़ते हैं क्योंकि दोनों में पात्रों को बदलना शामिल है, लेकिन पूरे विकास के दौरान पूरी तरह से अलग-अलग महत्वपूर्ण कार्य करते हैं।
यह देखने के लिए पेलोड का अंत-से-अंत तक परीक्षण करें कि पूरी प्रक्रिया के दौरान एन्कोडिंग और एस्केपिंग वास्तव में कहाँ मायने रखते हैं। %3Cimg%20src%3Dx%20onerror%3Dalert%281%29%3E को URL डिकोडर में पेस्ट करें और मार्कअप की तरह दिखने वाली स्ट्रिंग बन जाएं। फिर परिणाम को HTML एंटिटी एस्केपर में पेस्ट करके देखें कि टेक्स्ट कैसे सुरक्षित हो जाता है। दो टूल परतों को स्पष्ट रूप से दिखाई देते हैं।
टेकअवे: URL के लिए एनकोड करें, आउटपुट के लिए एस्केप करें - कैसे URL एनकोडर और डिकोडर और HTML इकाई एस्केपर दो अलग-अलग कार्यों के लिए एक उत्पाद में एक साथ बैठते हैं
मुख्य बात यह है कि एन्कोडिंग और एस्केपिंग पूरी तरह से अलग-अलग परतों पर अलग-अलग चिंताएँ हैं। URL एन्कोडिंग केवल संचरित संरचना की सुरक्षा करती है। आउटपुट एस्केपिंग प्रदान की गई सामग्री की सुरक्षा करता है। HTML तक पहुंचने पर सही ढंग से एन्कोड किए गए मान को अभी भी आउटपुट एस्केपिंग की आवश्यकता होती है। सही ढंग से निकाली गई स्ट्रिंग को कभी भी URL एन्कोडिंग की आवश्यकता नहीं होती है यदि उसे URL में नहीं डाला जाता है।
सही परत पर सही बचाव को सही मायने में लागू करें। XSS हमलों को रोकने के लिए URL एन्कोडिंग पर भरोसा न करें। URL संरचना को संरक्षित करने के लिए HTML एस्केपिंग पर भरोसा न करें। अपने डेटा प्रवाह को समझें और प्रत्येक चरण पर उचित परिवर्तन लागू करें। URL एनकोडर आपको यह देखने में मदद करता है कि एन्कोडिंग क्या करती है; फिर आउटपुट चरण के लिए HTML एंटिटी एस्केपर का उपयोग करें।