एमआईटी पाठ्यक्रम "कंप्यूटर सिस्टम सुरक्षा"। व्याख्यान 9: वेब अनुप्रयोग सुरक्षा, भाग 1

मैसाचुसेट्स इंस्टीट्यूट ऑफ टेक्नोलॉजी। व्याख्यान पाठ्यक्रम # 6.858। "कंप्यूटर सिस्टम की सुरक्षा।" निकोलाई ज़ेल्डोविच, जेम्स मिकेंस। 2014 साल

कंप्यूटर सिस्टम सुरक्षा सुरक्षित कंप्यूटर सिस्टम के विकास और कार्यान्वयन पर एक कोर्स है। व्याख्यान खतरे के मॉडल को कवर करते हैं, हमले जो सुरक्षा से समझौता करते हैं, और हाल के वैज्ञानिक कार्यों के आधार पर सुरक्षा तकनीक। विषयों में ऑपरेटिंग सिस्टम (OS) सुरक्षा, सुविधाएँ, सूचना प्रवाह प्रबंधन, भाषा सुरक्षा, नेटवर्क प्रोटोकॉल, हार्डवेयर सुरक्षा और वेब अनुप्रयोग सुरक्षा शामिल हैं।

व्याख्यान 1: "परिचय: खतरे के मॉडल" भाग 1 / भाग 2 / भाग 3
व्याख्यान 2: "हैकर हमलों का नियंत्रण" भाग 1 / भाग 2 / भाग 3
व्याख्यान 3: "बफर ओवरफ्लो: शोषण और संरक्षण" भाग 1 / भाग 2 / भाग 3
व्याख्यान 4: "पृथक्करण का पृथक्करण" भाग 1 / भाग 2 / भाग 3
व्याख्यान 5: "सुरक्षा प्रणालियाँ कहाँ से आती हैं?" भाग 1 / भाग 2
व्याख्यान 6: "अवसर" भाग 1 / भाग 2 / भाग 3
व्याख्यान 7: "मूल ग्राहक सैंडबॉक्स" भाग 1 / भाग 2 / भाग 3
व्याख्यान 8: "नेटवर्क सुरक्षा मॉडल" भाग 1 / भाग 2 / भाग 3
व्याख्यान 9: "वेब अनुप्रयोग सुरक्षा" भाग 1 / भाग 2 / भाग 3

वेब सुरक्षा कहानियों की हमारी भयानक श्रृंखला में दूसरा व्याख्यान शुरू करते हैं। मैं तुरंत उदाहरणों के त्वरित प्रदर्शन के लिए आगे बढ़ना चाहता हूं, क्योंकि आप जानते हैं कि हमारे डेमो लगभग कभी काम नहीं करते हैं। आशा है कि आज आप एक खाली स्क्रीन नहीं देखेंगे।

मूल विचार यह है कि मैं पहले आपको शेलशॉक त्रुटि का एक उदाहरण दिखाना चाहूंगा जिसके बारे में आपने पहले ही सुना होगा। यह कंप्यूटर सुरक्षा साहित्य में एक बहुत लोकप्रिय विषय था।



लोग खतरे की पैमाने पर 10 की अधिकतम रेटिंग के लिए एक हार्दिक त्रुटि देते हैं। वे इसे सबसे खतरनाक त्रुटि मानते हैं कि सुरक्षा प्रणाली को सुरक्षा करनी चाहिए। मैंने सोचा कि आपको इस मुद्दे का एक जीवंत इतिहास दिखाना बहुत अच्छा होगा कि आप अपने माता-पिता को रिटेल कर सकें, ताकि वे समझ सकें कि मैसाचुसेट्स इंस्टीट्यूट ऑफ टेक्नोलॉजी में पढ़ाई करना पैसे के लायक है।

तो शेलशॉक त्रुटि का मुख्य विचार क्या है? यह एक बहुत बड़ा उदाहरण है कि सुरक्षित वेब एप्लिकेशन बनाना इतना मुश्किल क्यों है, जो कई तकनीकों, कई भाषाओं, कई ऑपरेटिंग सिस्टम और इसी तरह आगे बढ़ता है। इसलिए, मुख्य विचार यह है कि शेलशॉक इस तथ्य का उपयोग करता है कि एक हमलावर सर्वर से एक विशेष http-request बना सकता है और इस अनुरोध में हेडर का प्रबंधन कर सकता है। मैंने बोर्ड पर एक बहुत ही सरल उदाहरण लिखा है।
मान लीजिए कि एक हमलावर बिल्लियों की खोज के विषय पर कुछ CGI को GET अनुरोध भेजना चाहता है, क्योंकि यह वही है जो लोग हमेशा इंटरनेट पर देखते हैं (केवल मजाक कर रहे हैं)। इसलिए, एक प्रश्न चिह्न होगा, और URL के साथ कुछ प्रकार के मानक होस्ट हेडर, उदाहरण के लिए, example.com:

Gqu /querry.cgi? खोज = बिल्लियाँ
होस्ट: example.com
कस्टम - हेडर: कस्टम - मूल्य

अब ध्यान दें कि एक हमलावर कस्टम हेडर भी निर्दिष्ट कर सकता है। उदाहरण के लिए, मैं वहां कुछ कस्टम-वैल्यू निर्दिष्ट करने के लिए कस्टम-हेडर नामक किसी प्रकार के एप्लिकेशन-विशिष्ट हेडर को ढूंढना चाहता हूं, क्योंकि वेब एप्लिकेशन कुछ कार्यक्षमता को परिभाषित कर सकता है जिसे सरल पूर्वनिर्धारित HTTP हेडर का उपयोग करके व्यक्त नहीं किया जा सकता है। तो जबकि यह सब हानिरहित लगता है।
लेकिन अंत में, क्या होता है कि CGI लिपियों को संसाधित करने के लिए इन वेब सर्वरों में से कई वास्तव में कस्टम मान हेडर से इन कस्टम मानों को स्वीकार करेंगे और उन्हें बैश वातावरण चर सेट करने के लिए उपयोग करेंगे। यही है, वे बैश चर के नाम के लिए एक कस्टम हेडर बनाने के लिए इस कस्टम-हेडर का उपयोग करेंगे, वे हमलावर द्वारा प्रदान किए गए इस कस्टम-मूल्य को लेंगे और इसे बैश चर के मूल्य के रूप में उपयोग करेंगे। इस चर को सेट करने के बाद, CGI सर्वर इस वातावरण के संदर्भ में कुछ प्रसंस्करण करेगा।

और यह बुरा है क्योंकि वेब सर्वर को इन बेतरतीब "गंदी" चीजों से मनमाना मूल्य नहीं लेना चाहिए। इस प्रकार, शेलशॉक त्रुटि के एक विशिष्ट उदाहरण में, क्या होता है कि यदि आप बैश चर को कुछ दुर्भावनापूर्ण मान देते हैं, तो पागलपन का एक रूप शुरू हो सकता है।



मूल रूप से, किसी फ़ंक्शन की यह दुर्भावनापूर्ण परिभाषा बैश स्क्रिप्टिंग भाषा में चुनी जाती है, और आपको इस प्रक्रिया की बारीकियों से परेशान नहीं होना चाहिए। लेकिन तथ्य यह है कि अगर बैश पैरामीटर सही तरीके से सेट किया गया था, तो / bin / id के इस भाग को निष्पादित नहीं किया जाएगा। तो आप बस कुछ प्रकार के गूंगा फ़ंक्शन को परिभाषित करते हैं जो कुछ भी नहीं करता है और क्वेरी प्रक्रिया को समाप्त करता है।

हालांकि, पात्रों का यह क्रम बैश पार्सर को भ्रमित करता है, यह स्लैश के बाद स्थित इस बकवास पर ठोकर लगता है। और फिर वह कहता है: "ओह, मैं यहाँ कुछ आज्ञाओं का विश्लेषण और निष्पादन जारी रख सकता हूँ, है ना?" और इस मामले में, यह केवल बिन / आईडी कमांड निष्पादित करता है, जो उपयोगकर्ता के बारे में कुछ जानकारी प्रदर्शित करता है। लेकिन भेद्यता का सार यह है कि बिन / आईडी के बजाय, आप यहां कोई भी कोड डाल सकते हैं!

मैं एक बहुत ही सरल उदाहरण दूंगा जो आप स्क्रीन पर देखेंगे। यह एक बहुत ही सरल पायथन सर्वर है, सबसे आसान जिसकी आप कल्पना कर सकते हैं। मैं यहाँ GET विधि का उपयोग करता हूँ। इस विधि का अर्थ है अनुरोध में सभी HTTP हेडर पर पुनरावृति।





यहां हेडर में हमारे पास वैरिएबल K के लिए एक मान है और क्वेरी V के लिए एक मान है। इस मामले में, यह केवल हेडर को ढूंढता है।

और फिर वह बहुत बेवकूफ बनाने जा रहा है - सिस्टम कॉल करने के लिए और हेडर में इंगित मूल्य पर सीधे शेल मूल्य सेट करें। तो यह भेद्यता की पूरी जड़ है।

यदि मैं अगले टैब पर जाता हूं और पीड़ित के वेब सर्वर को लॉन्च करता हूं, तो हम देखते हैं कि वह अनुरोधों को स्वीकार करने के लिए तैयार है।



फिर मैं अपना विशेष शेलशॉक क्लाइंट लिख सकता हूं - यह अगले टैब पर स्थित है।



वास्तव में, यह काफी सरल है - मैं इनमें से एक दुर्भावनापूर्ण हमले को परिभाषित करता हूं। यह रेखाएं हैं, इसलिए इसमें पहले "घुमावदार" मान हैं। और फिर मुझे बस इतना पता है कि सर्वर की तरफ अब सब कुछ मेरी मर्जी के मुताबिक होगा।

इस मामले में, मैंने कुछ हानिरहित उपयोग किया - इको "मैं आपकी कार का मालिक हूं।" लेकिन कुछ भी हो सकता है। आप "इको ATTACKER CMD" पैरामीटर के साथ एक और बैश शेल चला सकते हैं, यानी असली हमलावर का कमांड, जो बहुत खतरनाक हो सकता है।

इसलिए, मैं हेडर और यूजर रिक्वेस्ट सेट करता हूं, और फिर एक HTTP कनेक्शन बनाने के लिए केवल पायथन का उपयोग करता हूं और इसे सर्वर पर भेजता हूं। तो आखिर में क्या होता है? मैं यहां अपना शेलशॉक क्लाइंट चला रहा हूं।



आप देखें, त्रुटि 404 यहाँ दिखाई दी, क्योंकि इससे कोई फर्क नहीं पड़ता कि मैंने किस फ़ाइल का अनुरोध किया था, मैं यहाँ कुछ प्रकार के सूचकांक सम्मिलित करता हूँ जिनमें HTML मौजूद नहीं है। लेकिन अगर आप यहां देखें, तो दूसरे टैब पर, जहां हम पीड़ित के वेब सर्वर को दिखाते हैं, जो पोर्ट 8282 के माध्यम से कनेक्ट होने के लिए सहमत है, हम देखेंगे कि उसे मेरे संदेश "मैं आपकी कार का मालिक हूं" और ATTACKER CMD।



क्योंकि जैसे ही पीड़ित के सर्वर को यह हेडर प्राप्त हुआ, उसने तुरंत बैश वैरिएबल के मानों को सेट कर दिया, और परिणामस्वरूप, ATTACKER CMD कमांड लॉन्च किया गया। क्या यह स्पष्ट है?

श्रोता: क्या ऐसा होता है अगर कोई प्रोग्राम ऐसे शीर्षक से शुरू होता है?

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

श्रोता: इस प्रकार, यदि आप वेब सर्वर के कोड पर लौटते हैं, तो ऐसा लगता है कि शेलशॉक की तुलना में बहुत खराब भेद्यता है। क्योंकि आप एक सिस्टम कॉल कर सकते हैं और कस्टम हेडर को केवल किसी अन्य चीज़ पर सेट करके निष्पादित कर सकते हैं, और मुझे इस उदाहरण में शेलशॉक त्रुटि का उपयोग नहीं करना होगा।

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



एक और उदाहरण जो मैं आपको देना चाहता हूं वह क्रॉस-साइट स्क्रिप्टिंग का उदाहरण है। शेलशॉक की बग एक प्रकार का उदाहरण था कि सामग्री की कीटाणुशोधन कितनी महत्वपूर्ण है। हमने इस तथ्य पर चर्चा की कि आपको केवल यादृच्छिक लोगों से इनपुट स्वीकार नहीं करना चाहिए और इसे किसी भी प्रकार की टीमों में सीधे उपयोग करना चाहिए।

क्रॉस-साइट स्क्रिप्टिंग एक और उदाहरण है जो दिखाती है कि कुछ गलत क्यों हो सकता है। इस उदाहरण में, मेरे पास पायथन में लिखा गया एक और सरल सीजीआई सर्वर है।



यह वह हैंडल है जिसे क्लाइंट से रिक्वेस्ट मिलने पर निष्पादित किया जाता है। मैंने उत्तर के लिए यहां कुछ हेडर मुद्रित किए हैं, और मेरा उत्तर HTML टेक्स्ट होगा। जैसा कि यह पता चला है, ब्राउज़र में आपके द्वारा दिखाए जा रहे हमले को रोकने और रोकने के लिए कुछ सुरक्षा तंत्र हैं। इसलिए, मैंने शुरुआत में इस शीर्षक पट्टी को रखकर इस सुरक्षा के कुछ तंत्रों को निष्क्रिय करना संभव बना दिया।

CGI स्क्रिप्ट तब सभी फ़ील्ड और CGI अनुरोधों तक पहुँच प्राप्त करती है, जो लाइन फॉर्म = cgi.FieldStorage () से शुरू होती है। कल्पना करें कि इस प्रश्न चिह्न के बाद लाइन में स्थित सब कुछ हमारे उदाहरण के शीर्षक और मापदंडों का प्रतिनिधित्व करता है:

Gqu /querry.cgi? खोज = बिल्लियाँ
होस्ट: example.com
कस्टम - हेडर: कस्टम - मूल्य

इसके बाद, cgi स्क्रिप्ट एक बहुत ही सरल काम करती है - यह तुरंत उस चीज़ के मूल्य को प्रिंट करती है जो हमलावर से आई थी। यह एक ही मूल विचार है, और यह एक बुरा विचार है, क्योंकि यह प्रिंट फ़ंक्शन परिणामी मूल्य को सीधे HTML में ही प्रिंट करता है।

यहाँ निम्नलिखित हो सकता है। मान लीजिए कि मेरे पास प्रश्नों का एक समूह है, जिन्हें मैं चलाना चाहता हूं। इस पहले अनुरोध में, मैं केवल हैलो को संदेश मान सेट करता हूं, अर्थात, मैं पहली पंक्ति के पते पर जाता हूं।



इसलिए, यदि मैं अपने पृष्ठ पर जाता हूं, तो मुझे उस पर हैलो शब्द दिखाई देगा, क्योंकि सर्वर सीधे उस चीज़ को स्वीकार करता है जो मैं उस पर से गुजरता हूं और "हैलो" प्रिंट करता हूं। तो कोई आश्चर्य नहीं।



मैं समझता हूं कि मैं वास्तव में मनमाने ढंग से HTML कोड पास कर सकता हूं, और अगर मैं h1 हेडर के लिए प्रारूप सेट करता हूं, अर्थात, मैं सर्वर पर हैलो में समाप्त होने वाली दूसरी पंक्ति भेजूंगा, तो यह पृष्ठ पर भी बदल जाएगा - आप देखते हैं, शब्द शैली h1 हेडर शैली में बदल गई है। तो यह काम करता है, मैं सीधे पेज में मान टाइप करता हूं।



महान, अब हम व्यवसाय में हैं, और यह अच्छा है। अब बस जावास्क्रिप्ट कोड जोड़ते हैं, अर्थात्, हम ब्राउज़र में मेरे द्वारा तैयार की गई तीसरी लाइन को चलाते हैं, जहाँ एक निश्चित स्क्रिप्ट डाली जाती है, जो कि अलर्ट ("XSS") पैरामीटर के बाद चलती है।

तो अब हम एक खाली स्क्रीन देखते हैं। ऐसा लगता है कि हम सफल नहीं हुए, क्योंकि कोई भी आउटपुट दिखाई नहीं देता है, और मैंने कोई चेतावनी नहीं देखी।



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

लेकिन आप इस तथ्य का लाभ उठा सकते हैं कि एचटीएमएल, सीएसएस और जावास्क्रिप्ट बेहद जटिल भाषाएं हैं, और उन्हें समझने में मुश्किल में लिखा गया है। मैं इसका लाभ उठाऊंगा और अपनी प्रविष्टि की अंतिम, चौथी पंक्ति का उपयोग करके इसे ब्राउज़र के एड्रेस बार में रखूंगा। यह एक अमान्य URL वाला हमला स्ट्रिंग है। इसमें छवि का URL <IMG ""> और स्क्रिप्ट टैग "> और वास्तव में पार्स नहीं किया जा सकता है। इसलिए, इस तरह की एक पंक्ति प्राप्त होने पर, ब्राउज़र बस भ्रमित हो जाता है और स्क्रीन पर जानकारी प्रदर्शित करता है: "127.0.0.1:8282 पर पेज कहता है: XSS"। इस प्रकार, अंतर्निहित क्रॉस-साइट स्क्रिप्टिंग डिटेक्शन वास्तव में काम नहीं करता है।



यदि हम "ओके" बटन पर क्लिक करते हैं, तो हमारे पास सिर्फ एक खाली पेज होगा। लेकिन यदि आप इसकी सामग्री को देखते हैं, तो हम असंगत उद्धरण और कोष्ठक देखेंगे जो कहीं से नहीं आते हैं।



हालांकि, हमलावर के दृष्टिकोण से, क्षतिग्रस्त पृष्ठ कोई फर्क नहीं पड़ता, क्योंकि हमने एक चेतावनी देखी, जिसका अर्थ है कि कोड लॉन्च किया गया था। और इसका उपयोग कुकीज़ चुराने या ऐसा कुछ करने के लिए किया जा सकता है।

श्रोता: क्रॉस-साइट पहलू क्या है?

प्रोफेसर: क्रॉस-साइट पहलू यह है कि अगर कोई हमलावर किसी उपयोगकर्ता को URL पर जाने के लिए मना सकता है, जैसे कि इस उदाहरण में, तो वह वह व्यक्ति है जो संदेश की सामग्री निर्धारित करता है। यह वह है जो XSS चेतावनी या ऐसा कुछ बनाता है। अनिवार्य रूप से, क्या होता है कि पीड़ित का पृष्ठ किसी ऐसे व्यक्ति की ओर से कोड निष्पादित करता है जो इस पृष्ठ का प्रबंधन नहीं करता है।

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

वेबसाइटों में उपयोगकर्ता दस्तावेज़ हो सकते हैं, जैसे Google या Office 365 दस्तावेज़। ये सभी दस्तावेज़ अविश्वसनीय लोगों से आते हैं, लेकिन किसी तरह उन्हें एक-दूसरे के साथ और Google या Microsoft के महान बुनियादी ढांचे के साथ प्राप्त करने की आवश्यकता होती है।

हम किस प्रकार के क्रॉस-साइट सुरक्षा परिदृश्यों का उपयोग कर सकते हैं? एक प्रकार की सुरक्षा ब्राउज़र में ही क्रॉस-साइट स्क्रिप्टिंग फ़िल्टर है। ये फ़िल्टर संभावित क्रॉस-साइट स्क्रिप्टिंग हमलों का पता लगाने का प्रयास करेंगे। और हमने इनमें से एक फिल्टर को कार्रवाई में देखा - यह उस परिदृश्य का तीसरा उदाहरण था जिसकी हमने जांच की थी।
मान लीजिए कि आपके पास URL foo.com/?q= <script src = "bad.com/cookie stealer.js"> है। यही है, यह पता एक स्क्रिप्ट चलाता है जो उपयोगकर्ता को दुर्भावनापूर्ण साइट पर रीडायरेक्ट करता है और उससे कुकीज़ चुराता है।



इसलिए, ब्राउज़र इसे निष्पादित करने से इंकार कर देगा और इस हमलावर की चाल काम नहीं करेगी। कारण सरल है - ब्राउज़र ने केवल यह देखने के लिए जाँच की कि क्या इस URL में अंतर्निहित <script> है और इसे पाया, इस लिंक पर क्लिक करने से मना किया। इस प्रकार, यह पता लगाने के लिए एक बहुत ही सरल अनुमान है कि क्या कुछ हानिकारक हो रहा है, क्योंकि कोई भी सामान्य डेवलपर इस तरह की बातों को संबोधित नहीं करेगा। ऐसी चीजों को सक्षम या अक्षम करने के लिए आप अपने ब्राउज़र कॉन्फ़िगरेशन विकल्पों को कॉन्फ़िगर कर सकते हैं। यह कभी-कभी परीक्षण के लिए उपयोगी होता है यदि आप बस जल्दी और बहुत सत्यापन के बिना कुछ जावास्क्रिप्ट डेटा दर्ज करना चाहते हैं। लेकिन आमतौर पर ब्राउज़र में यह चेक डिफ़ॉल्ट रूप से सक्षम होता है।

उदाहरण के लिए, Chrome और IE में एक अंतर्निहित फ़िल्टर होता है जो पता बार में URL मान को देखता है और समान चीजों के लिए दिखता है। और अगर वे वहां हैं, तो ब्राउज़र उन्हें पूरी तरह से हटाने या <> अंदर स्रोत बनाने की कोशिश कर सकता है। ऐसे कई विश्लेषण के तरीके हैं जिनके आधार पर ब्राउज़र को ऐसी चीजों का पता लगाना चाहिए। और अगर आप OWASP वेबसाइट को देखते हैं, तो क्रॉस-साइट स्क्रिप्टिंग का पता लगाने के लिए इस तरह के अनुमान का उपयोग करने के उदाहरण हैं और इस फ़िल्टर को कैसे बायपास किया जाए इसके उदाहरण हैं।

आप जानते हैं, यह बहुत मज़ेदार था, क्योंकि पहले हमारे व्याख्यान के लिए एक उदाहरण के रूप में मैंने ऐसा ही कुछ किया था, और यह काम नहीं किया। तब मैंने OWASP की चीट शीट पर ध्यान दिया और जो चौथा विकल्प काम किया, वह एक उदाहरण था, जो img छवि पते के टूटे हुए पार्सिंग के साथ था।

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

श्रोता: लेकिन क्या ऐसी चीज़ों की जाँच करना ब्राउज़र की ज़िम्मेदारी नहीं है?

प्रोफेसर: मेरा मतलब है कि जब ब्राउज़र प्रॉक्सी सर्वर पर होता है और प्रॉक्सी इस उदाहरण में दिखाया गया है। यही है, अंतर्निहित फ़िल्टर अर्थ बनाते हैं, क्योंकि ब्राउज़र के अंदर कई पार्सर हो सकते हैं, और ये फ़िल्टर ब्राउज़र के अंदर हैंडलर परतों की सुरक्षा के लिए उपयोग किए जाते हैं।

श्रोता: मुझे लगता है कि हम कह सकते हैं कि यह वेब डेवलपर की ज़िम्मेदारी है, उपयोगकर्ता की नहीं, ऐसी चीज़ों की जाँच करने की।

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

एक तरह से या किसी अन्य, फ़िल्टर एक आदर्श समाधान नहीं हैं और जो लगातार, या लगातार क्रॉस-साइट स्क्रिप्टिंग हमलों, लगातार XSS के रूप में जाना जाता है, उसे रोक नहीं सकता है। यह एक प्रकार का प्रतिबिंब है, क्योंकि स्क्रिप्ट कोड केवल URL में "रहता है"। जैसे ही उपयोगकर्ता ने इस URL को बंद किया, हमला समाप्त हो गया।

लेकिन कल्पना करें कि किसी उपयोगकर्ता ने आपकी साइट के टिप्पणी अनुभाग में दुर्भावनापूर्ण HTML रखा है। , . , .



, – . HTML- .

? - , . HTML, , . .

: , , , , - ?

: , . , — post. , , XML HTTP .

: , , …

: , , . , . - , .

, , .

, « HTTP », HTTP-only cookie. , , JavaScript cookie. , , , : «, , JavaScript, cookie»! - .

, , . , . , JavaScript cookie, - , , URL- - , , buy.com. , , , Ferrari, attacker, .



, JavaScript, cookie, , URL-. , CSRF , .

, , , . , , . , - , , , Google, Office 365 . . , Google googleusercontent.com. , Gmail . -, 25- .



? , - , google.com. , google.com. .

, – . , -, , . , . — Django. -, , -.



Django , , . – . CSS , . , . Django , : , .



-. , Django, Django : «, -, , , CGI». Django , , . - CGI0, , .

हालांकि, Django बहुत बेहतर करता है - यह उपयोगकर्ता सामग्री को कीटाणुरहित करता है, क्योंकि यह उससे एक चाल की उम्मीद करता है। यह बस नाम चर के मूल्य को तुरंत यहां रखता है, और इसे इस तरह से एन्कोड करता है कि यह सामग्री कभी भी HTML संदर्भ से बाहर नहीं निकल सकती है और जावास्क्रिप्ट कोड या ऐसा कुछ निष्पादित कर सकती है।

26:25 मि

एमआईटी पाठ्यक्रम "कंप्यूटर सिस्टम सुरक्षा"। व्याख्यान 9: "वेब अनुप्रयोग सुरक्षा," भाग 2


पाठ्यक्रम का पूरा संस्करण यहां उपलब्ध है ।

हमारे साथ बने रहने के लिए धन्यवाद। क्या आप हमारे लेख पसंद करते हैं? अधिक दिलचस्प सामग्री देखना चाहते हैं? एक आदेश रखकर या अपने दोस्तों को इसकी अनुशंसा करके हमें समर्थन दें, एंट्री-लेवल सर्वरों के अनूठे एनालॉग पर हैबर उपयोगकर्ताओं के लिए 30% छूट जो हमने आपके लिए ईजाद की है: VPS (KVM) E5-2650 v4 (6 कोर) 10GB DDR4 240GB SSD 1Gbps से पूरा सच $ 20 या सर्वर को कैसे विभाजित करें? (विकल्प RAID1 और RAID10 के साथ उपलब्ध हैं, 24 कोर तक और 40GB DDR4 तक)।

VPS (KVM) E5-2650 v4 (6 करोड़) 10GB DDR4 240GB SSD 1Gbps दिसंबर तक मुफ्त में जब छह महीने की अवधि के लिए भुगतान करते हैं, तो आप यहां ऑर्डर कर सकते हैं ।

डेल R730xd 2 बार सस्ता? केवल हमारे पास 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps नीदरलैंड और यूएसए में $ 249 से 100 टीवी है ! इन्फ्रास्ट्रक्चर Bldg का निर्माण कैसे करें के बारे में पढ़ें । एक पैसा के लिए 9,000 यूरो की लागत डेल R730xd E5-2650 v4 सर्वर का उपयोग कर वर्ग?