ASP.NET अनुरोधों की वैधता: <से? मैं [az! / \!] | & # XSS टाइप -1 WAF के लिए।

“ASP.NET में प्रश्नों को मान्य करने की क्षमता बुनियादी इनपुट नियंत्रण करने के लिए डिज़ाइन की गई है। वेब अनुप्रयोगों की सुरक्षा के संबंध में निर्णय लेने का इरादा नहीं है। केवल डेवलपर्स ही यह निर्धारित कर सकते हैं कि उनके कोड को किस सामग्री पर प्रक्रिया करनी चाहिए। Microsoft किसी भी स्रोत से प्राप्त सभी इनपुट की जाँच करने की सलाह देता है। हम अपने ग्राहकों द्वारा सुरक्षित अनुप्रयोगों के विकास को सुविधाजनक बनाने का प्रयास करते हैं, और इस दिशा में डेवलपर्स की सहायता के लिए अनुरोध सत्यापन कार्यशीलता को डिज़ाइन और कार्यान्वित किया गया। हमारी विकास सिफारिशों के बारे में अधिक जानकारी के लिए, MSDN लेख पढ़ें: msdn.microsoft.com/en-us/library/ff649487.aspx#pagguidelines0001_inputdatavalidation । "

Microsoft सुरक्षा प्रतिक्रिया केंद्र ASP.NET अनुरोध सत्यापन आधिकारिक स्थिति

ASPR.NET में क्वेरी सत्यापन को बाईपास करने के एक और तरीके की खोज के बारे में क्वोटियम रिसर्च सेंटर की हालिया रिपोर्ट में MSRC द्वारा इस तरह की अचानक प्रतिक्रिया के बावजूद, यह ध्यान देने योग्य है कि वेब एप्लिकेशन की सुरक्षा के संबंध में निर्णय लेने का इरादा नहीं है। यह उस वर्ग के नाम से समर्थित है जो चेक के मुख्य सेट को लागू करता है (System.Web.CrossSiteScriptingValidation) और इसका सार, जिसमें XSS टाइप -1 हमलों (क्रॉस-साइट स्क्रिप्टिंग का परिलक्षित निष्पादन) और वेब स्टैक के डेवलपर्स से मूल लेख के एक निश्चित सबसेट को रोकने में शामिल है। । एक अन्य सवाल यह है कि इस कार्यक्षमता को कितनी प्रभावी ढंग से लागू किया जा सकता है और मौजूदा आदिम नियमित फिल्टर से पूर्ण वेब अनुप्रयोग फ़ायरवॉल कैसे प्राप्त किया जा सकता है जो किसी भी XSS टाइप -1 वैक्टर से बचाता है?

इस प्रश्न का उत्तर देने के लिए, आपको .NET फ्रेमवर्क के विभिन्न संस्करणों में क्वेरी सत्यापन के कार्यान्वयन, इसकी सीमाओं, जाने-माने वर्कअराउंड और इसकी कार्यक्षमता के विस्तार की संभावनाओं के विवरण को समझने की आवश्यकता है।

1. ASP.NET का विकास सत्यापन का अनुरोध करता है

ASP.NET के सभी संस्करणों में (.NET फ्रेमवर्क के संस्करणों के साथ मेल खाना), v1.1 से शुरू होता है और v4.5 के साथ समाप्त होता है, एक नियमित सेट की श्रृंखलाओं की घटनाओं के लिए HTTP अनुरोध के विभिन्न तत्वों में खोज करने के लिए क्वेरी सत्यापन कम हो जाता है, जो खतरनाक मूल्यों की एक ब्लैकलिस्ट का वर्णन करता है। कोडिंग की दृष्टि से, यह मानक मान्यता के बिना भावों का उपयोग किए बिना, एक मान्यता ऑटोमेटन द्वारा कार्यान्वित किया जाता है, प्रदर्शन कारणों से मैन्युअल रूप से लागू किया जाता है। कई खतरनाक मूल्यों में एचटीएमएल भाषा के तत्व शामिल हैं जो आउटपुट दस्तावेज़ की अखंडता का उल्लंघन कर सकते हैं यदि वे पर्याप्त प्रारंभिक प्रसंस्करण के बिना इसमें उपयोग किए जाते हैं।

पहली बार, क्वेरी सत्यापन तंत्र ASP.NET v1.1 में लागू किया गया था और काफी व्यापक ब्लैकलिस्ट का उपयोग किया था। अनुरोध प्रक्रिया अवरुद्ध कर दी गई थी यदि क्वेरी स्ट्रिंग या प्रपत्र फ़ील्ड मानों में से कोई भी पैरामीटर नियमित अभिव्यक्तियों में से किसी के अनुरूप हो:

• <? i [az! /]
• (? i: स्क्रिप्ट) \ s? \:
• (? i: on [az]) * \ s * =
• (? i: ex) प्रेसियन \ (

यह आश्चर्यजनक नहीं है कि डेवलपर्स ने बड़ी संख्या में झूठी सकारात्मकता के कारण इस सुविधा को पूरी तरह से अक्षम करना पसंद किया। इसलिए, ASP.NET v2.0 में, कई खतरनाक मान बहुत कम हो गए और v4.5 अपरिवर्तित हो गए:

• # और
• <? i [az! / \?]

ASP.NET v4.0 की तैयारी के चरण के दौरान, डेवलपर्स ने यह भी घोषणा की कि सेट (? I: स्क्रिप्ट) \ s?: सूची में वापस आ जाएगा, लेकिन यह v4.0 या v4.5 में नहीं हुआ।

न केवल कई खतरनाक मूल्य संस्करण से संस्करण में बदल गए हैं, बल्कि सत्यापन की गुंजाइश और डेवलपर्स के लिए इस प्रक्रिया को नियंत्रित करने के लिए उपलब्ध संभावनाएं भी हैं। इसलिए, v2.0 में व्यक्तिगत पृष्ठों के लिए अनुरोध सत्यापन को अक्षम करना संभव हो गया, और v4.0 में तथाकथित तथाकथित एक नया मोड आस्थगित दानेदार सत्यापन, जिसमें प्रत्येक पैरामीटर की जाँच की जाती है जब इसे वेब एप्लिकेशन कोड से एक्सेस किया जाता है, और अनुरोध के प्रारंभिक प्रसंस्करण के चरण में नहीं। V4.0 के साथ शुरू, क्वेरी स्ट्रिंग मापदंडों और फार्म क्षेत्र मूल्यों के अलावा, सत्यापन क्षेत्र भी शामिल हैं:

• सभी तत्वों के मूल्य Request.Cookies से;
• डाउनलोड की गई फ़ाइलों के नाम Request.Files से;
• Request.RawUrl, Request.Path और Request.PathInfo मान

2. ASP.NET v4.x में अनुरोधों की वैधता

ASP.NET के हाल के संस्करणों में, अनुरोध सत्यापन के भाग के रूप में, कई अतिरिक्त चेक भी किए जाते हैं जो इसके जीवन चक्र के शुरुआती चरणों में किए जाते हैं। उनकी पूरी सूची तालिका में दी गई है:

निरीक्षण	सेटिंग्स और मूल्यों
Request.Path की लंबाई की जाँच करना	<HttpRuntime> सेक्शन में maxUrlLength विशेषता। इसे संपूर्ण अनुप्रयोग के लिए और व्यक्तिगत वर्चुअल पथों या पृष्ठों के लिए वैश्विक रूप से परिभाषित किया जा सकता है। 260 वर्णों से अधिक लंबे पथ वाले HTTP अनुरोध के प्रसंस्करण को अवरुद्ध करता है। यह मान IIS या http.sys में परिभाषित सीमा तक बढ़ाया जा सकता है।
क्वेरी स्ट्रिंग वाले Request.RawUrl टुकड़ा की लंबाई की जाँच करना	<HttpRuntime> अनुभाग में maxQueryStringLength विशेषता। इसे संपूर्ण अनुप्रयोग के लिए और व्यक्तिगत वर्चुअल पथों या पृष्ठों के लिए वैश्विक रूप से परिभाषित किया जा सकता है। 2048 वर्णों से लंबे समय तक क्वेरी स्ट्रिंग वाले HTTP अनुरोध के प्रसंस्करण को अवरुद्ध करता है। यह मान IIS या http.sys की सीमा तक बढ़ाया जा सकता है।
ASP.NET में संभावित रूप से खतरनाक किसी भी वर्ण के लिए Request.Path को स्कैन करें	RequestPathInvalidCharacters <httpRuntime> अनुभाग में विशेषता है। इसे संपूर्ण अनुप्रयोग के लिए और व्यक्तिगत वर्चुअल पथों या पृष्ठों के लिए वैश्विक रूप से परिभाषित किया जा सकता है। यदि किसी पथ में कोई भी वर्ण है, तो HTTP अनुरोध के प्रसंस्करण को अवरुद्ध करता है: <(XSS हमले) > (XSS हमले) * (फ़ाइल नामों के विहितीकरण पर हमले) % (URL डिकोडर अटैक) : (वैकल्पिक NTFS डेटा धाराओं पर हमला) & (क्वेरी स्ट्रिंग पार्सर पर हमले) \ _ (फ़ाइल पथ के विहितीकरण पर हमले) ? (क्वेरी स्ट्रिंग पार्सर पर हमले) RequestPathInvalidCharacters विशेषता में, अवैध वर्ण दोहरे उद्धरण चिह्नों में संलग्न होते हैं और अल्पविराम द्वारा अलग किए जाते हैं। पथ "\ .." के लिए वर्णों का अनुक्रम इस सूची में इस तथ्य के कारण शामिल नहीं है कि IIS v6 + स्वचालित रूप से URI के विहितकरण को ठीक से करता है, ऐसे अनुक्रमों को सही ढंग से संसाधित करता है। व्यवहार में, मार्ग में आगे की स्लैश की उपस्थिति से जुड़ी त्रुटियां भी नहीं होती हैं, क्योंकि विमुद्रीकरण की प्रक्रिया में उन्हें रिवर्स द्वारा प्रतिस्थापित किया जाता है।
प्रत्येक Request.Path मान के लिए उपयुक्त प्रबंधित कॉन्फ़िगरेशन ढूँढना	<HttpRuntime> अनुभाग में रिलैक्सUrlToFileSystemMapping विशेषता। यह केवल पूरे आवेदन के लिए विश्व स्तर पर निर्धारित किया जा सकता है। डिफ़ॉल्ट रूप से, यह विशेषता गलत पर सेट होती है, जिसे URL में घटक पथ पर विचार करने के लिए ASP.NET की आवश्यकता होती है जो NTFS नियमों का अनुपालन करने वाला एक वैध फ़ाइल पथ है। यह प्रतिबंध विशेषता मान को सही पर सेट करके अक्षम किया जा सकता है।
संभावित खतरनाक मानों के लिए Request.QueryString, Request.Form, Request.Files, Request.Cookies, Request.Path, Request.PathInfo, Request.RawUrl चेक करना	<HttpRuntime> अनुभाग में RequestValidationMode विशेषता। इसे संपूर्ण अनुप्रयोग के लिए और व्यक्तिगत वर्चुअल पथों या पृष्ठों के लिए वैश्विक रूप से परिभाषित किया जा सकता है। वह मोड सेट करता है जिसमें वेब एप्लिकेशन के अनुरोधों को मान्य किया जाएगा। 4.0 के मान (डिफ़ॉल्ट) में आस्थगित दानेदार सत्यापन शामिल है, जो तब होता है जब वेब एप्लिकेशन कोड सीधे वैध क्षेत्र से तत्वों तक पहुंचता है। इस विशेषता को 2.0 पर सेट करना ASP.NET के पिछले संस्करणों में उपयोग किए गए सत्यापन मोड को लौटाता है। <HttpRuntime> अनुभाग में requestValidationType विशेषता। यह केवल पूरे आवेदन के लिए विश्व स्तर पर निर्धारित किया जा सकता है। क्वेरी सत्यापन विधि को लागू करने वाले RequestValidator वर्ग के उत्तराधिकारी के प्रकार को सेट करता है। डिफ़ॉल्ट रूप से, System.Web.Util.RequestValidator वर्ग का उपयोग किया जाता है।

अंतिम जाँच हिमखंड के उस दृश्य भाग को, जिसे क्वेरी सत्यापन कहा जाता है, और इसकी कार्यक्षमता का विस्तार करने के लिए वेब एप्लिकेशन डेवलपर्स के लिए उपलब्ध है।

3. अनुरोध सत्यापन की आंतरिक संरचना

ASP.NET v2.0 + में अनुरोधों को मान्य करने के लिए डिफ़ॉल्ट रूप से प्रयुक्त System.Web.Util.RequestValidator वर्ग के IsValidRequestString विधि का स्रोत कोड कुछ इस तरह दिखता है:

protected internal virtual bool IsValidRequestString( HttpContext context, string value, RequestValidationSource requestValidationSource, string collectionKey, out int validationFailureIndex) { if (requestValidationSource == RequestValidationSource.Headers) { validationFailureIndex = 0; return true; } return !CrossSiteScriptingValidation.IsDangerousString(value, out validationFailureIndex); } 

यह ध्यान दिया जाना चाहिए कि IsValidRequestString पद्धति को कॉल करने से पहले भी शून्य बाइट की सभी घटनाएं मान पैरामीटर में पारित स्ट्रिंग से कट जाती हैं। यह व्यवहार HttpRequest वर्ग के ValidateString विधि में लागू किया गया है और डेवलपर द्वारा इसे ओवरराइड नहीं किया जा सकता है।

जैसा कि आप स्रोत कोड से देख सकते हैं, क्वेरी सत्यापन के लिए मुख्य कार्यक्षमता क्रॉसडाइटस्क्रिप्टिंग विधि वर्ग के IsDangerousString विधि में लागू की गई है:

 internal static bool IsDangerousString(string s, out int matchIndex) { matchIndex = 0; int startIndex = 0; while (true) { int num2 = s.IndexOfAny(startingChars, startIndex); if (num2 < 0) { return false; } if (num2 == (s.Length - 1)) { return false; } matchIndex = num2; char ch = s[num2]; if (ch != '&') { if ((ch == '<') && ((IsAtoZ(s[num2 + 1]) || (s[num2 + 1] == '!')) || ((s[num2 + 1] == '/') || (s[num2 + 1] == '?')))) { return true; } } else if (s[num2 + 1] == '#') { return true; } startIndex = num2 + 1; } } 

जाहिर है, यह फिल्टर एक ऑटोमेटन है जो नियमित सेट की श्रृंखलाओं की घटना को पहचानता है <? I [az! / \!] & # # स्ट्रिंग में इसे पारित कर दिया। इसके अलावा, CrossSiteScriptingValidation वर्ग उन दो सहायक विधियों को भी परिभाषित करता है जो उनकी कार्यक्षमता को बढ़ाने या बदलने के लिए उपलब्ध नहीं हैं:

 internal static bool IsDangerousUrl(string s) { if (string.IsNullOrEmpty(s)) { return false; } s = s.Trim(); int length = s.Length; if (((((length > 4) && ((s[0] == 'h') || (s[0] == 'H'))) && ((s[1] == 't') || (s[1] == 'T'))) && (((s[2] == 't') || (s[2] == 'T')) && ((s[3] == 'p') || (s[3] == 'P')))) && ((s[4] == ':') || (((length > 5) && ((s[4] == 's') || (s[4] == 'S'))) && (s[5] == ':')))) { return false; } if (s.IndexOf(':') == -1) { return false; } return true; } internal static bool IsValidJavascriptId(string id) { if (!string.IsNullOrEmpty(id)) { return CodeGenerator.IsValidLanguageIndependentIdentifier(id); } return true; } 

पहले वाला URL चेक करता है और खतरनाक सभी मानों को मानता है जो ^ (?: I: https! :) | [^]] सेट को संतुष्ट नहीं करते हैं। दूसरा भाषा पहचानकर्ताओं के लिए व्याकरण नियम के खिलाफ तर्क के मूल्य की जाँच करता है: ^ ((I: [a-z _] [a-z0-9 _]) $। ASP.NET v1.1 में क्वेरी सत्यापन के भाग के रूप में दोनों तरीकों को IsDangerousString से बुलाया गया था। अन्य सभी संस्करणों में, वे केवल कुछ ASP.NET वेबफ़ॉर्म नियंत्रण में कार्यात्मक सत्यापन विधियों के रूप में उपयोग किए जाते हैं और एक RequestValidException नहीं बढ़ाते हैं।

4. मानक कार्यान्वयन के नुकसान और इसे बाईपास करने के तरीके

जाहिर है, क्वेरी सत्यापन के मानक कार्यान्वयन में कई कमियां हैं जो वेब एप्लिकेशन की सुरक्षा के संबंध में निर्णय लेने के लिए वास्तव में अनुपयुक्त हैं।

सबसे पहले, जांच किए गए चेक केवल XSS टाइप -1 हमलों के एक सीमित सबसेट से रक्षा कर सकते हैं, जिन्हें बाहर ले जाने के लिए एक टैग खोलने की आवश्यकता होती है। इस घटना में कि प्रतिबिंबित XSS का हमला क्लाइंट स्क्रिप्ट के टैग, विशेषता या कोड के अंदर पैरामीटर मान को एम्बेड करने के परिणामस्वरूप संभव है, मानक क्वेरी सत्यापन इसे रोकने में सक्षम नहीं होगा।

दूसरे, ब्लैकलिस्ट नियंत्रण, अपने आप में, सुरक्षा का पर्याप्त उपाय नहीं है। यह मानक क्वेरी सत्यापन को बायपास करने के कई प्रसिद्ध तरीकों की उपस्थिति के कारण है:

• <? I [az! / \?] पर प्रतिबंध को उद्घाटन कोण कोष्ठक और टैग नाम (<% img src = # onerror = alert (1) />) के बीच प्रतिशत चिह्न का उपयोग करके परिवृत्त किया जा सकता है। इस मामले में, HTML पार्सर IE v9- इसे एक वैध टैग परिभाषा पर विचार करेगा। कुछ मामलों में, यदि कोई वेब अनुप्रयोग क्वेरी मापदंडों के यूनिकोड कैनोनिकलाइज़ेशन को लागू करता है, तो यूनिकोड-वाइड मान (% uff1c img% 20src% 3D% 23% 20onerrer% 3Dalert% 281% 29% 2f% uff1e) का उपयोग करके बायपास करना भी संभव है।
• प्रतिबंध ((मैं? मैं: स्क्रिप्ट) \ s? \: और (? मैं: पूर्व) प्रेसियन \ (स्क्रिप्ट के अंदर व्हाट्सएप का उपयोग करता है और अभिव्यक्ति के बीच और खुलने वाली ब्रैकेट (जावा% 09 स्क्रिप्ट): अलर्ट (1) और अभिव्यक्ति% 09 ( सतर्क (1))।
• # & # पर प्रतिबंध HTML संस्थाओं के नामांकित संदर्भों के अस्तित्व को ध्यान में नहीं रखता है, जिसका उपयोग कई वैक्टर (जावास्क्रिप्ट% 26Tab ;: अलर्ट (1)) में भी किया जा सकता है। यहां यह भी ध्यान दिया जाना चाहिए कि ASP.NET HTML डिकोडर (HttpUtility.HtmlDubble) के मानक कार्यान्वयन "केवल 253 नामित संस्थाओं के संदर्भों के बारे में" जानता है, जबकि HTML मानक उनमें से काफी अधिक परिभाषित करता है । यह आपको कई HTML संस्थाओं को आउटपुट डॉक्यूमेंट में फेंकने की अनुमति देता है, भले ही वेब एप्लिकेशन इनपुट डेटा की प्रारंभिक प्रसंस्करण के स्तर पर पैरामीटर मानों का HTML डिकोडिंग करता हो।

लेकिन मानक कार्यान्वयन का सबसे महत्वपूर्ण दोष अनुरोध प्रसंस्करण चरण है, जिस पर इसका सत्यापन किया जाता है। यहां तक ​​कि स्थगित मोड के साथ, पहले से उत्पन्न प्रतिक्रिया दस्तावेज़ की सामग्री के बारे में जानकारी के बिना, किसी विशेष हमले के वर्ग के लिए एक विशेष पैरामीटर के खतरों के बारे में सही धारणा बनाना असंभव है। उदाहरण के लिए, यदि HTML मार्कअप तत्वों वाला कोई पैरामीटर सर्वर की प्रतिक्रिया में नहीं आता है, तो यह XSS टाइप -1 के दृष्टिकोण से अपने संभावित खतरे को मुखर करने के लिए अजीब है। यह इस बात के बारे में है कि चयन मानों को बिना यह जानना खतरनाक है कि वे SQL क्वेरी में समाप्त होते हैं। इसी तरह के तर्क के बाद, ASP.NET डेवलपर्स को क्वेरी सत्यापन में SQL सिंटैक्स तत्वों, पथ पथ, XPath अभिव्यक्तियों और अन्य वर्ण अनुक्रमों के लिए एक खोज शामिल करनी चाहिए जो किसी भी भाषा में इंजेक्शन लगाने के लिए विशिष्ट हैं, बजाय खुद को हमलों के एक छोटे से उपसमूह तक सीमित करने के लिए। XSS विशिष्ट प्रकार। बेशक, यह दृष्टिकोण बहुत सारी झूठी सकारात्मकताएँ उत्पन्न करता है, जो संपूर्ण अनुप्रयोग के लिए सत्यापन को पूरी तरह से अक्षम करने की ओर ले जाता है, और ऐसे उपकरणों के उद्भव के लिए जो आपको बहुत प्रयास किए बिना ऐसा करने की अनुमति देता है (उदाहरण के लिए, nuget.org/packages-DisableRequestValidation )।

फिर भी, अगले भाग में चर्चा किए गए अवसर का लाभ उठाकर इन सभी कमियों को समाप्त किया जा सकता है।

5. क्वेरी सत्यापन कार्यक्षमता का विस्तार

ASP.NET v4.0 के साथ शुरू, डेवलपर्स के पास क्वेरी सत्यापन की कार्यक्षमता का विस्तार करने का अवसर है, जिसमें शामिल हैं मानक कार्यान्वयन को पूरी तरह से पुनर्परिभाषित करना। इसे पूरा करने के लिए, यह System.eb.Util.RequestValidator वर्ग के लिए वारिस बनाने के लिए पर्याप्त है, इसमें IsValidRequestString विधि को ओवरराइड करके। यह तरीका तब कहा जाता है जब अगले अनुरोध पैरामीटर को जांचना आवश्यक होता है और निम्नलिखित तर्क लेता है:

• HttpContext संदर्भ - HTTP अनुरोध का संदर्भ जिसमें चेक किया जाता है;
• स्ट्रिंग मान - चेक किया जाने वाला मान;
• RequestValidationSource requestValidationSource - वह स्रोत जिसके लिए चेक किया गया मान है;
• string collectionKey - स्रोत में चेक किए गए मान का नाम;
• int validationFailureIndex से बाहर - एक आउटपुट पैरामीटर जिसमें एक मान अंदर होता है, जिसमें से एक खतरनाक चरित्र का पता चला था या -1;

उदाहरण के लिए, वर्णों के संयोजन का उपयोग करके सत्यापन को बायपास करने की क्षमता को समाप्त करने के लिए <%, आप निम्नलिखित एक्सटेंशन को लागू कर सकते हैं:

 using System; using System.Web; using System.Web.Util; namespace RequestValidationExtension { public class BypassRequestValidator : RequestValidator { public BypassRequestValidator() { } protected override bool IsValidRequestString( HttpContext context, string value, RequestValidationSource requestValidationSource, string collectionKey, out int validationFailureIndex) { validationFailureIndex = -1; for (var i = 0; i < value.Length; i++) { if (value[i] == '<' && (i < value.Length - 1) && value[i + 1] == '%') { validationFailureIndex = i; return false; } } return base.IsValidRequestString( context, value, requestValidationSource, collectionKey, out validationFailureIndex); } } } 

फिर, वेब अनुप्रयोग कॉन्फ़िगरेशन के httpRuntime अनुभाग में RequestValidationType = "RequestValidationExtension.BypassRequestValidator" विशेषता का मान सेट करके, एक वेब एप्लिकेशन प्राप्त करें जो सत्यापन को दरकिनार करने की इस विधि से सुरक्षित है।

6. बेहतर क्वेरी सत्यापन

क्वेरी सत्यापन की कार्यक्षमता का विस्तार करने की क्षमता का उपयोग करना, वर्तमान कार्यान्वयन की सभी मौजूदा समस्याओं को खत्म करना और पूर्ण-आधारित XSS टाइप -1 WAF प्राप्त करना काफी संभव है। इसके लिए, अनुरोध मापदंडों के मूल्यों का सत्यापन प्रतिक्रिया भेजने से पहले तुरंत किया जाना चाहिए जब यह पहले से ही उत्पन्न हो और इसकी सामग्री ज्ञात हो। प्रतिक्रिया की अखंडता पर क्वेरी मापदंडों के प्रभाव के एक विश्वसनीय मूल्यांकन के लिए यह एक आवश्यक शर्त है। हालांकि, ASP.NET अनुरोध सत्यापन वास्तुकला अपने कार्यात्मक के ढांचे के भीतर इसे निष्पादित करने की क्षमता प्रदान नहीं करता है, जिससे पूरी प्रक्रिया को तीन चरणों में तोड़ने की आवश्यकता होती है।

पहले चरण की कार्यक्षमता सीधे मानक क्वेरी सत्यापन के विस्तार में लागू की जाती है। इस स्तर पर, चेक किए जा रहे प्रत्येक पैरामीटर का सेट ^ के साथ मिलान किया जाता है? मैं [A-Za-z0-9 _] + $ और, अगर तुलना पास नहीं होती है, तो पैरामीटर को बाद में चेक किए जाने के रूप में चिह्नित किया जाता है। इस प्रकार, सभी संभावित खतरनाक क्वेरी मापदंडों के बारे में जानकारी एकत्र की जाती है, जिसके लिए एक जांच का अनुरोध किया गया था (अर्थात, अनुरोध को संसाधित करते समय वास्तव में वेब अनुप्रयोग में उपयोग किए जाने वाले पैरामीटर)। यह क्वेरी सत्यापन की मौजूदा वास्तुकला के साथ पूर्ण एकीकरण सुनिश्चित करता है, और अतिरिक्त जांच के लिए अतिरिक्त रूप से ज्ञात-खतरनाक मापदंडों को अधीन करने की आवश्यकता को भी समाप्त करता है।

दूसरा चरण एक ASP.NET आउटपुट फ़िल्टर है और स्ट्रीम की निगरानी को लागू करता है जिसमें प्रतिक्रिया के सभी टुकड़े उत्पन्न होते हैं, जो अनुरोध जीवन चक्र के विभिन्न चरणों में बनते हैं। संपूर्ण प्रतिक्रिया की सामग्री को तीसरे चरण में प्रसंस्करण के लिए भी संग्रहीत किया जाता है।

तीसरा चरण, एक HTTP मॉड्यूल के रूप में कार्यान्वित किया जाता है जो एंडरसाइज इवेंट को संसाधित करता है, दूसरे चरण में प्राप्त प्रतिक्रिया की अखंडता पर पहले चरण में एकत्र किए गए सभी मापदंडों के प्रभाव का आकलन करता है। यदि प्रतिक्रिया की अखंडता का उल्लंघन पाया जाता है, तो चेक को विफल माना जाता है। अखंडता पर क्वेरी मापदंडों के प्रभाव का आकलन तथाकथित सम्मिलन बिंदुओं के जवाब में एक फजी खोज पर आधारित है - उन स्थानों पर जहां प्रतिक्रिया टुकड़ा लगभग किसी भी पैरामीटर के मूल्य के साथ मेल खाता है। सम्मिलन बिंदुओं का सेट एक सम्मिलन मानचित्र बनाता है, जिसकी मदद से पैरामीटर मानों में निषिद्ध वर्णों की उपस्थिति के लिए बहुत अधिक उचित जांच की जा सकती है, साथ ही प्रतिक्रिया की अखंडता पर उनके प्रभाव की प्रकृति को प्रकट किया जा सकता है।

अंतिम कार्य सभी भाषाओं के पार्सरों का उपयोग करके हल किया जाता है जो प्रतिक्रिया (एचटीएमएल, जावास्क्रिप्ट, सीएसएस) में पाया जा सकता है। डालने के नक्शे से डेटा के साथ प्रतिक्रिया के विभिन्न टुकड़ों को पार्स करके प्राप्त पार्स पेड़ों की तुलना पूरी जानकारी देती है कि एक या किसी अन्य पैरामीटर के मूल्य के साथ प्रतिक्रिया में पेड़ के कौन से नोड्स एम्बेडेड थे।


वर्णित एल्गोरिथ्म का प्रूफ-ऑफ-कॉन्सेप्ट कार्यान्वयन GitHub पर उपलब्ध है । लेखन के समय, इस फ़िल्टर को बायपास करने के लिए कोई ज्ञात तरीके नहीं हैं। परीक्षणों से पता चला कि उन मामलों में वेब एप्लिकेशन के प्रदर्शन पर कोई ठोस प्रभाव नहीं है जहां अनुरोध में खतरनाक मूल्य और 7-15% धीमी प्रतिक्रिया पीढ़ी शामिल नहीं है। यह देखते हुए कि प्रूफ-ऑफ-कॉन्सेप्ट संस्करण तीसरे पक्ष के पार्सर का उपयोग करता है जो प्रतिक्रिया सत्यापन एल्गोरिथ्म के ढांचे के भीतर की तुलना में बहुत अधिक सामान्य समस्या को हल करता है, इन घटकों का इष्टतम कार्यान्वयन उत्पादक वातावरण में समाधान के विश्वसनीय अनुप्रयोग के लिए पर्याप्त प्रदर्शन प्राप्त करेगा।

7. निष्कर्ष

ASP.NET के वर्तमान संस्करणों में क्वेरी सत्यापन कार्यक्षमता का कार्यान्वयन अक्षम है और XSS टाइप -1 वर्ग के हमलों के खिलाफ सुरक्षा की समस्या को हल नहीं करता है। हालांकि, इसकी वर्तमान वास्तुकला और विस्तार क्षमताएं इस आलेख में वर्णित प्रतिक्रिया सत्यापन विधि का उपयोग करके स्वतंत्र रूप से हल करने की अनुमति देती हैं।

हालांकि, हमें यह नहीं भूलना चाहिए कि इस तरह के हमलों के खिलाफ सबसे प्रभावी संरक्षण तीसरे पक्ष के घुड़सवार समाधान नहीं हैं, बल्कि स्वयं डेवलपर्स द्वारा इनपुट और आउटपुट डेटा के प्रसंस्करण का सही कार्यान्वयन है। और इरव या अधिक जटिल उत्पादों (जैसे कि IIS या .netIDS के लिए मॉड-सुरक्षा ) का उपयोग डेवलपर को सुरक्षित कोड विकसित करने के लिए बुनियादी नियमों का पालन करने से नहीं बचाता है (उदाहरण के लिए, www.troyhunt.com/2011/12/free-ebook-owasp-top -10-for-net.html या wiki.mozilla.org/WebAppSec/Secure_Coding_Guinelines )।