एमआईटी पाठ्यक्रम "कंप्यूटर सिस्टम सुरक्षा"। व्याख्यान 8: नेटवर्क सुरक्षा मॉडल, भाग 2

मैसाचुसेट्स इंस्टीट्यूट ऑफ टेक्नोलॉजी। व्याख्यान पाठ्यक्रम # 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

तो क्या होता है अगर ब्राउज़र वस्तु को सही ढंग से संसाधित नहीं करता है और उसके प्रकार की पहचान नहीं कर सकता है? इस मामले में, आपको सुरक्षा समस्याएं हो सकती हैं। उनमें से एक को MIME हमला कहा जाता है।

आप शायद MIME से परिचित हैं - यह एक प्रकार का अनएन्क्रिप्टेड हेडर है जैसे टेक्स्ट / html, image.jpeg और इसी तरह। इसलिए, IE ब्राउज़र के पुराने संस्करणों ने इसका उपयोग किया क्योंकि उन्हें लगा कि यह उपयोगकर्ता की मदद करेगा। लेकिन कभी-कभी ऐसा होता है कि वेब सर्वर ऑब्जेक्ट फ़ाइल के गलत एक्सटेंशन को असाइन करते हैं।

एक गलत तरीके से कॉन्फ़िगर किया गया वेब सर्वर प्रत्यय। Html को संलग्न कर सकता है। इसमें वास्तव में एक्सटेंशन .jpeg, या इसके विपरीत है, उदाहरण के लिए, foo.html के बजाय foo.jpg बनाएं।



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

लेकिन यह एक स्पष्ट भेद्यता है! मान लीजिए कि पृष्ठ में कुछ निष्क्रिय सामग्री है, उदाहरण के लिए, एक हमलावर द्वारा नियंत्रित डोमेन से एक छवि। हालांकि, पीड़ित का पेज सोचता है: “भले ही यह एक दुर्भावनापूर्ण हैकर साइट की सामग्री है, यह केवल निष्क्रिय सामग्री है। वह मेरे लिए कुछ नहीं कर सकता है! " एक चरम मामले में, एक असफल छवि प्रदर्शित की जाएगी, लेकिन यह किसी भी कोड को खोलने में सक्षम नहीं होगा, क्योंकि निष्क्रिय सामग्री शून्य विशेषाधिकार है।



लेकिन तथ्य यह है कि IE इस छवि को पहले "सूंघ" सकता है, इसकी पहली 256 बाइट्स। और एक हमलावर जानबूझकर HTML और जावास्क्रिप्ट कोड वहां डाल सकता है। तब यह पता चलता है कि पीड़ित की साइट वही लाएगी जिसे वह छवि मानता है, और IE एम्बेडेड पृष्ठ के संदर्भ में दुर्भावनापूर्ण कोड निष्पादित करेगा।

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

आइए तख्ते और खिड़की की वस्तुओं (ऑब्जेक्ट जो एक DOM दस्तावेज़ वाली विंडो हैं) को देखें। फ्रेम्स इन स्वतंत्र जावास्क्रिप्ट ब्रह्मांडों का प्रतिनिधित्व करते हैं जिनके बारे में हमने यहां बात की है। मेरा मतलब है, JavaScript DOM नोड का एक उदाहरण है, जैसा कि DOM ट्री की तस्वीर में दिखाया गया है।

इस तरह, यह जावास्क्रिप्ट के लिए दिखाई देने वाली इस पदानुक्रम में DOM नोड ऑब्जेक्ट के रूप में मौजूद होगा।

जावास्क्रिप्ट में, विंडो ऑब्जेक्ट वास्तव में वैश्विक नामस्थान के लिए एक उपनाम है। यह एक बेवकूफ विचार की तरह लगता है। यही है, अगर आपको वैश्विक चर x का नाम पता था, तो आप इसे window.x नाम से भी एक्सेस कर पाएंगे।

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

उदाहरण के लिए, एक फ्रेम इस तरह शुरू हो सकता है: .xyzcom, यहां आप एक सेकंड के लिए योजना और प्रोटोकॉल को अनदेखा कर सकते हैं।

इस मामले में, हम यह मान सकते हैं कि मूल का स्रोत (document.domain) प्रत्यय yzcom है। इसी तरह, इस दस्तावेज़ का मूल स्रोत अभिव्यक्ति z.com है। यह संभव है क्योंकि z.com yzcom का एक प्रत्यय है।



केवल एक चीज जो इस तरह के स्रोत के रूप में सेवा नहीं कर सकती है वह है अभिव्यक्ति .ayzcom, क्योंकि यह मूल उत्पत्ति के स्रोत के लिए गलत प्रत्यय है। इसके अलावा, उत्पत्ति के स्रोत के सही स्रोत प्रत्यय को केवल .com नहीं माना जा सकता है, क्योंकि इस मामले में साइट किसी भी तरह की कुकीज़ या कुछ को प्रभावित करने में सक्षम होगी। जैसे किसी भी साइट पर। जिसके परिणाम विनाशकारी हो सकते हैं।

इस प्रकार की चीजें क्यों स्वीकार्य हैं, इसकी प्रेरणा यह है कि यह किसी प्रकार के मौजूदा भरोसेमंद रिश्ते से संबंधित है। तो ऐसा लगता है कि शीर्ष तीन मापदंडों के साथ सब कुछ क्रम में है, और विकार केवल .com में है।

श्रोता: यह पता चलता है कि किसी भी बिंदु पर या अंतिम बिंदु पर इस तरह के विभाजन करना संभव है? उदाहरण के लिए, क्या आपका xyzcom आपके z.com में बदला जा सकता है?

प्रोफेसर: नहीं, यह केवल हर बिंदु पर लागू होता है।



श्रोता: क्या यह एक कारण है कि ऐसा नहीं किया गया ताकि आप एक सुपर या उपडोमेन का संकेत दे सकें, लेकिन साथ ही उन्हें किसी तरह इस बात पर सहमत होना चाहिए कि जानकारी कहाँ से आएगी? मान लीजिए कि मैं केवल उसी को स्वीकार करना चाहता हूं जिसमें मेरा मूल है, ताकि इन संसाधनों में से कोई भी मुझ पर हमला कर सके। इसके अलावा, हम इस बातचीत को सममित बना देंगे, ताकि मैं भी इसे प्रभावित कर सकूं। आखिरकार, स्रोत का प्रत्यय .com का अर्थ है कि जो कुछ भी समान है .com प्रत्यय मुझे प्रभावित कर सकता है।

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

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

इसका एक कारण है, जिसे हम एक सेकंड में विचार करेंगे। इस प्रकार, दो फ्रेम एक दूसरे तक पहुंच सकते हैं यदि निम्न में से कम से कम दो स्थितियां सत्य हैं:

• फ्रेम के दोनों सेट (डॉक्यूमेंट.डोमेन) एक ही मूल्य;
• इनमें से कोई भी फ़्रेम बदल नहीं सकता है (document.domain), इस तथ्य के बावजूद कि दोनों फ़्रेमों में इस दस्तावेज़ का मूल्य समान है।

इन नियमों का मुख्य विचार यह है कि वे डोमेन को अपनी त्रुटियों या किसी उप-डोमेन की हानिकारकता के कारण हमले से बचाते हैं।

कल्पना करें कि आपके पास एक xyzcom डोमेन है जो yzcom डोमेन पर हमला करने की कोशिश कर रहा है क्योंकि पहले डोमेन में कोई त्रुटि है या दुर्भावनापूर्ण है। वह .com लुक में yzcom डोमेन को छोटा करने की कोशिश करेगा, और फिर जावास्क्रिप्ट, या कुकीज़, या अन्य चीजों के साथ "क़मीज़" शुरू करेगा।



तो, इन दो नियमों का मतलब है कि अगर yzcom किसी के साथ बातचीत करने की अनुमति नहीं देना चाहता है, तो यह कभी भी मूल्य (document.domain) को नहीं बदलेगा। इसलिए जब xyzcom फ्रेम इसे छोटा करना चाहता है, तो ब्राउज़र कहेगा: "हाँ, आप इसे छोटा करना चाहते हैं, लेकिन आपको इसे करने का कोई अधिकार नहीं है!" मूल्यों का संयोग है, लेकिन yzcom डोमेन ने संकेत नहीं दिया है कि वह इसमें भाग लेना चाहता है। क्या यह स्पष्ट है? इस मामले में, यह देखा जा सकता है कि ज्यादातर फ्रेम एक ही मूल नीति के साथ काम करते हैं।

अब हम देख सकते हैं कि हमारे DOM नोड को कैसे संसाधित किया जाता है। यह बहुत सरल है। आमतौर पर, डोम नोड्स को आसपास के फ्रेम से मूल मिलता है। कुकीज़ के मामले में, यह कुछ अधिक जटिल है। कुकीज़ में एक डोमेन होता है और उनका अपना तरीका होता है। उदाहरण के लिए, आप कल्पना कर सकते हैं कि एक कुकी निम्नलिखित जानकारी से जुड़ी हो सकती है, उदाहरण के लिए * .mit.edu / 6.858। इस स्थिति में, कुकी के पास एक * .mit.edu / डोमेन और पथ 6.858 है।



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

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

एक सुरक्षित ध्वज सुरक्षा ध्वज है जिसे आप कुकी पर सेट करके बता सकते हैं कि यह HTTPS फ़ाइल है। इस स्थिति में, HTTP सामग्री को इस कुकी तक पहुंच नहीं होनी चाहिए। यह कुकीज़ का मुख्य विचार है।

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

श्रोता: यदि वे इन नियमों का अनुपालन करते हैं तो क्या फ्रेम एक दूसरे की कुकीज़ तक पहुँच सकते हैं?

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

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

इस प्रकार, कुकीज़ सुरक्षा के लिए एक बहुत महत्वपूर्ण संसाधन हैं। और कई नेटवर्क सुरक्षा हमलों को चोरी करने और उन्हें नुकसान पहुंचाने के लिए उपयोग करने के लिए डिज़ाइन किया गया है।
कुकीज़ से जुड़ा एक और दिलचस्प सवाल है। मान लीजिए आपके पास एक साइट foo.co.uk है। क्या होगा यदि इस होस्टनाम वाली साइट co.uk के लिए कुकीज़ सेट करने में सक्षम है?



यहां उन नियमों से संबंधित एक सूक्ष्मता है, जिनके बारे में हमने पहले चर्चा की थी, क्योंकि पहली साइट को अपने डोमेन को छोटा करने और दूसरे के लिए कुकीज़ सेट करने में सक्षम होना चाहिए, यहां सब कुछ कानूनी लगता है। लेकिन मानवीय दृष्टिकोण से, हम इसे संदेह की नजर से देखते हैं, क्योंकि हम समझते हैं कि co.uk एक एकल परमाणु डोमेन है। हालाँकि, यह .com के बराबर है। हम यह कह सकते हैं कि अंग्रेजों ने यह कह दिया कि उन्हें यहाँ एक बिंदु होना चाहिए। लेकिन यह उनकी गलती नहीं है। नैतिक दृष्टिकोण से, यह एक एकल डोमेन है जिसे तोड़ा नहीं जा सकता। इसलिए, ठीक से काम करने के लिए कुकीज़ सेट करने के लिए हमारे पास कुछ विशेष अवसंरचना होनी चाहिए।

Mozilla की एक वेबसाइट publicsuffix.org है जिसमें कुकीज़, उत्पत्ति और डोमेन को कैसे छोटा किया जाना चाहिए, इस बात को ध्यान में रखते हुए नियमों की सूची है कि कुछ चीजों में डॉट्स हो सकते हैं, जबकि वास्तव में उन्हें एक ही परमाणु माना जाना चाहिए पूरा।

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

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

लेकिन जैसे-जैसे इंटरनेट अधिक लोकप्रिय हुआ, लोगों ने कहना शुरू किया: "हे, शुरुआत में हमने समाधानों की एक बड़ी डिजाइन तैयार की थी और अब हमें इसे उन लोगों के लिए उपयुक्त बनाना होगा जो हमारी भाषा की संकीर्ण समझ का उपयोग करने के लिए मजबूर हैं।" इसलिए, अब हम इन सभी पागल समस्याओं का सामना करते हैं।

विचार करें कि HTTP XML प्रतिक्रियाओं को उसी मूल स्रोत नीति द्वारा कैसे नियंत्रित किया जाता है। यदि यह इसके मूल सर्वर पर बनाया गया है, तो डिफ़ॉल्ट रूप से, जावास्क्रिप्ट केवल उनमें से एक उत्पन्न कर सकता है। हालाँकि, एक नया इंटरफ़ेस है जिसे क्रॉस ओरिजिन रिक्वेस्ट, या कॉर्स कहा जाता है।

इसलिए, यह वही मूल है, जब तक कि सर्वर ने इस CORS को सक्षम नहीं किया है। मूल रूप से, एक नया HTTP प्रतिसाद शीर्ष लेख जोड़ा जाता है जिसे एक्सेस-कंट्रोल-अनुमति-उत्पत्ति कहा जाता है।



मान लीजिए कि foo.com से जावास्क्रिप्ट एक XML HTTP अनुरोध करना चाहता है। जैसा कि नियमों में वर्णित है, क्रॉस-ऑरिजिन यहां होता है। और अगर bar.com सर्वर इसे अनुमति देना चाहता है, तो वह अपनी HTTP प्रतिक्रिया को शीर्षक के साथ लौटा देगा: "हाँ, मैं foo.com को ये क्रॉस-मूल XML XML अनुरोध भेजें।"

दरअसल, bar.com सर्वर "नहीं" का जवाब दे सकता है, अर्थात यह अनुरोध को अस्वीकार कर सकता है। इस स्थिति में, ब्राउज़र HTTP XML अनुरोध को पूरा नहीं कर सकता है। तो यह एक तरह की नई बात है, जो ज्यादातर मिश्रित अनुप्रयोगों के कारण दिखाई देती है। विभिन्न डेवलपर्स और विभिन्न डोमेन के अनुप्रयोगों के लिए यह आवश्यक है, ताकि उन्हें एक-दूसरे के साथ डेटा का आदान-प्रदान करने का अवसर मिले।



इसलिए foo.com के बजाय, यहाँ कोई तारांकन हो सकता है यदि कोई क्रॉस-ऑरिजनल डेटा प्राप्त करना चाहता है, और इसी तरह। मुझे लगता है कि यह बहुत आसान है। अन्य संसाधनों का एक समूह है जो हम देख सकते हैं, जैसे कि चित्र। Access-Control-Allow-Origin के लिए धन्यवाद, एक फ्रेम किसी भी स्रोत से छवियों को लोड कर सकता है जो वह चाहता है। लेकिन वह इस छवि के बिट्स की जांच नहीं कर सकता है, क्योंकि यह माना जाता है कि उत्पत्ति के स्रोतों की विभिन्न नीतियों के साथ एक-दूसरे की फ़ाइलों की सामग्री की जांच करना अच्छा नहीं है।

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

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

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



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

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



इस प्रकार, हालांकि मूल नीतियां आपको स्क्रिप्ट टैग की सामग्री को सीधे देखने की अनुमति नहीं देती हैं, आप बस निर्दिष्ट ऑपरेशन कर सकते हैं और स्रोत कोड प्राप्त कर सकते हैं।

इसी तरह, आप अपने डोमेन से अपने होम सर्वर को प्राप्त कर सकते हैं, बस उस पर स्रोत कोड प्राप्त कर सकते हैं और फिर उसे आपको वापस भेज सकते हैं। यही है, वास्तव में, आपने बस अपने घर के सर्वर को इस तरह से स्रोत कोड प्राप्त करने के लिए Wget प्रोग्राम को चलाने के लिए कहा है। इसलिए यह थोड़ा मूर्खतापूर्ण भी लगता है, अर्थात यहाँ की मूल नीति थोड़ी अजीब है।

श्रोता: मान लीजिए कि ऐसा करने का कारण उपयोगकर्ता को जावास्क्रिप्ट प्राप्त करने से रोकना है, क्योंकि तब कुकीज़ भी भेजी जा सकती हैं। यही है, उपयोगकर्ता अपनी आवश्यकताओं के परिणामस्वरूप जावास्क्रिप्ट को अनुकूलित करने में सक्षम होगा।

प्रोफेसर: हाँ, यह है।

श्रोता: तो अगर आपको ऐसा करने के लिए अपना सर्वर मिलता है, तो यह आपको कस्टम कुकीज़ प्रदान करने में सक्षम नहीं होगा।

प्रोफेसर: यह सच है, हालांकि व्यवहार में "कच्चे" स्रोत कोड को उपयोगकर्ता द्वारा फिर से काम करने का इरादा नहीं है। लेकिन आप सही हैं कि इससे कुछ हमलों को रोका जा सकेगा।

, , JavaScript, . , - , -, , . , , , . , , .

, . - - , - HTML JavaScript. , , . .

, JavaScript, , . Java, .



, HTML5 , , , , Java. , .

, HTTP, cookie. , URL, ?



, URL- bank.com. , - . , URL, , , $500 . , .

— , origin, bank.com - , , cookie . : «, , , $500 attacker! , ».
तो एक समस्या है। यह हमला आग लगाता है, क्योंकि वास्तव में, एक हमलावर अनुभवजन्य रूप से यह निर्धारित कर सकता है कि यह कमांड कैसे दिखना चाहिए। इस टीम में कोई मौका नहीं है। अनिवार्य रूप से, एक हमलावर अपने स्वयं के बैंक खाते पर यह कोशिश कर सकता है, यह पता लगा सकता है कि यह प्रोटोकॉल कैसा दिखता है, और फिर किसी तरह उपयोगकर्ता के ब्राउज़र को हमलावर के नाम पर स्थानांतरण कार्रवाई करने के लिए मजबूर करता है। यह वही है जिसे क्रॉस-साइट अनुरोध जालसाजी, संक्षिप्त सीएसआरएफ कहा जाता है।

यदि आप उत्पन्न URL में कुछ यादृच्छिकता शामिल करते हैं तो इस तरह के हमले से इंकार किया जा सकता है। एक प्रकार के दुर्घटनाएं जो एक हमलावर का अनुमान नहीं लगा सकता है।

कल्पना करें कि बैंक के वेब पेज के अंदर कुछ फॉर्म है। एक रूप वह है जो वास्तव में हमारे मामले में समान अनुरोध उत्पन्न करता है:

<form action = “/transfer.cdi”…> 

और इस फॉर्म के अंदर, हमारे पास इनपुट डेटा होगा, जो आमतौर पर टेक्स्ट, कीस्ट्रोक्स, माउस क्लिक, और इस तरह दर्ज करने के लिए उपयोग किया जाता है। वास्तव में, हम इस इनपुट को छिपा सकते हैं ताकि यह उपयोगकर्ता के पेज पर दिखाई न दे: इनपुट प्रकार = "छिपा हुआ", इसे विशेषता नाम = "csrf" और यादृच्छिक मान मान = "a72f ..." दें। यह फॉर्म सर्वर पर जनरेट होगा।



इस प्रकार, जब उपयोगकर्ता इस पृष्ठ पर जाता है, तो सर्वर की ओर, सर्वर इस यादृच्छिकता मूल्य = "a72f ..." को उत्पन्न करता है और उपयोगकर्ता द्वारा प्राप्त HTML में इसे एम्बेड करता है। इसलिए, जब उपयोगकर्ता इस फॉर्म को भरता है, तो यह फॉर्म का URL:

bank.com/xfer?amount=500&to=attacker

यह एक यादृच्छिक टोकन के साथ पूरक है:

 http://bank.com/xfer?amount=500&to=attacker/&csrf=a72f... 

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

58:00 मिनट

जारी रखा:

एमआईटी पाठ्यक्रम "कंप्यूटर सिस्टम सुरक्षा"। व्याख्यान 8: नेटवर्क सुरक्षा मॉडल, भाग 3


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

हमारे साथ बने रहने के लिए धन्यवाद। क्या आप हमारे लेख पसंद करते हैं? अधिक दिलचस्प सामग्री देखना चाहते हैं? एक आदेश रखकर या अपने दोस्तों को इसकी अनुशंसा करके हमें समर्थन दें, एंट्री-लेवल सर्वरों के अनूठे एनालॉग पर हैबर उपयोगकर्ताओं के लिए 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 100 टीवी 249 डॉलर में नीदरलैंड और यूएसए से है! इन्फ्रास्ट्रक्चर Bldg का निर्माण कैसे करें के बारे में पढ़ें । एक पैसा के लिए 9,000 यूरो की लागत डेल R730xd E5-2650 v4 सर्वर का उपयोग कर वर्ग?