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

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

श्रोता: URL में हमेशा एक यादृच्छिक टोकन क्यों शामिल होता है, और अनुरोध निकाय में नहीं?

प्रोफेसर: HTTPS का उपयोग इस तरह से किया जाता है, लेकिन अनुरोध निकाय में यादृच्छिक चर शामिल नहीं करने का कोई अच्छा कारण नहीं है। बस यह है कि वंशानुक्रम के कुछ रूप हैं जो URL के माध्यम से काम करते हैं लेकिन व्यवहार में, आप शीर्ष लेख को छोड़कर, इस जानकारी को HTTPS अनुरोध में कहीं और रख सकते हैं।

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



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

<script> var x = “ntrusted”; </script> 

तब वह HTTP एक्सएमएल अनुरोध को लागू करने में सक्षम होगा, जिसे एम्बेडेड पेज के प्राधिकरण के साथ निष्पादित किया जाएगा।

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

एक और बात है कि आपको नेटवर्क पते पर ध्यान देने की आवश्यकता है। वे हमारी बातचीत के उस हिस्से से संबंधित हैं, जिसमें कहा गया था कि हमलावर XML HTTP अनुरोध के माध्यम से कौन संवाद नहीं कर सकता है।

नेटवर्क पतों के बारे में, फ्रेम HTTP (HT +) अनुरोधों (होस्ट + पोर्ट) को उसके मूल के अनुरूप भेज सकता है। ध्यान दें कि एक ही स्रोत की एक ही नीति की सुरक्षा डीएनएस बुनियादी ढांचे की सुरक्षा से बहुत निकट से संबंधित है, क्योंकि इस प्रकार की सभी नीतियां आपके द्वारा कहे गए पर आधारित हैं।

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

यह निम्नानुसार किया जाता है। सबसे पहले, एक हमलावर एक डोमेन नाम पंजीकृत करता है, हमलावर.कॉम का कहना है। यह बहुत सरल है, बस कुछ रुपये का भुगतान करें - और जाने पर, आपका अपना डोमेन नाम है। हमलावर को भी हमलावर सर्वर में स्थित वस्तुओं के नाम पर आने वाले अनुरोधों का जवाब देने के लिए DNS सर्वर को कॉन्फ़िगर करना होगा।



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

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

तो उसके बाद क्या होगा? ब्राउजर हमलावर.कॉम के लिए डीएनएस क्वेश्चन जेनरेट करना शुरू कर देगा क्योंकि आपके द्वारा देखे गए पेज में ऑब्जेक्ट्स होते हैं जो हमलावर डॉट कॉम पर स्थित ऑब्जेक्ट से लिंक होते हैं। लेकिन ब्राउज़र यह कहने जा रहा है: "मैंने इस डोमेन को पहले कभी नहीं देखा है, इसलिए मुझे हमलावर.कॉम से संपर्क करने की अनुमति के लिए DNS अनुरोध भेजें"!



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

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

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



एक हमलावर DNS ऐसा क्यों कर सकता है? क्योंकि हैकर इसे इसके लिए सेट करता है, और घुसपैठिए के DNS सर्वर को पीड़ित.कॉम के साथ पुन: कनेक्ट करने के लिए परामर्श करने की आवश्यकता नहीं है।

इसके अलावा, अगर हमारी साइट के माध्यम से एक नई वस्तु प्राप्त करना चाहता है, तो AJAX, यह विचार करेगा कि यह AJAX अनुरोध कहीं बाहर कहीं attacker.com पर जाता है, लेकिन वास्तव में यह AJAX अनुरोध पीड़ित.कॉम को, अंदर जाता है। यह बुरा है, क्योंकि अब हमारे पास यह कोड उस तरफ है, जिस पर हमलावर.com वेब पेज स्थित है, जो वास्तव में पीड़ितों के डेटा तक पहुंच प्राप्त करता है।



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

श्रोता: यह हमलावर के कुकीज़ और इसी तरह के सभी पाने के लिए पीड़ित.कॉम से, इसके विपरीत कोई हमला करना समझदारी नहीं होगी?

प्रोफेसर: हाँ, वह विकल्प भी काम करेगा। यह आपको पोर्ट स्कैनिंग जैसी अच्छी चीजें करने की अनुमति देगा। मेरा मतलब है, आपका दृष्टिकोण सही तरीके से काम करेगा। क्योंकि आप कर सकते हैं, कदम से कदम, लगातार विभिन्न कंप्यूटर नाम और पीड़ित। नेटवर्क के भीतर विभिन्न बंदरगाहों के लिए हमलावर। Com। दूसरे शब्दों में, हमलावर.कॉम वेब पेज हमेशा यह सोचेगा कि यह हमलावर.कॉम पर जाता है और वहां से AJAX का अनुरोध प्राप्त करता है।

वास्तव में, जब भी DNS सर्वर हमलावर.कॉम से जुड़ता है, तो वह पीड़ित.कॉम नेटवर्क के अंदर कुछ अन्य आईपी पते के लिए अनुरोध भेजता है। इस तरह, वह बस एक-एक करके आईपी पते के माध्यम से "चल" सकता है और देख सकता है कि कोई इन अनुरोधों का जवाब दे रहा है या नहीं।

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

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

श्रोता: क्या यह अटैक विधि HTTPS के माध्यम से काम करती है?

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

श्रोता: अगर पीड़ित केवल HTTPS का उपयोग करता है तो क्या होगा?

प्रोफेसर: मुझे लगता है कि यह हमलावर को रोक देगा।

श्रोता: एक हमलावर मुख्य रूप से अपने आईपी पते के साथ पीड़ित के कंप्यूटर पर प्रतिक्रिया क्यों करता है?

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

तो आप इसे कैसे ठीक कर सकते हैं? इस भेद्यता को ठीक करने का एक तरीका DNS क्लाइंट रिसॉल्वर को संशोधित करना है ताकि बाहरी होस्ट नामों को आंतरिक आईपी पते तक पहुंचने की अनुमति न हो।

यह इस तरह की बेवकूफी है कि आपके नेटवर्क के बाहर का कोई व्यक्ति ऐसा DNS बनाने में सक्षम होना चाहिए जो आपके नेटवर्क के अंदर किसी चीज़ से जुड़ा हो। यह सबसे सरल उपाय है।



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

और अब हम वही स्रोत नीति की रक्षा करते हैं, जिसे हम देखेंगे। पिक्सल के बारे में क्या? मूल नीति पिक्सल की सुरक्षा कैसे करती है?

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

यह वास्तव में एक समस्या है क्योंकि इसका मतलब है कि माता-पिता के फ्रेम बच्चे के फ्रेम के ऊपर आकर्षित कर सकते हैं। और यह, बदले में, बहुत कपटी हमलों का कारण बन सकता है।

मान लीजिए कि एक हमलावर एक पेज बनाता है जो कहता है, "iPad जीतने के लिए यहां क्लिक करें।" वही मानक चाल। यह पैरेंट फ्रेम है।



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

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



अब, एक हमलावर स्क्रीन के क्षेत्र पर इस फ्रेम को ओवरले कर सकता है जिसे उपयोगकर्ता को मुफ्त आईपैड प्राप्त करने के लिए क्लिक करना होगा, और इस फ्रेम को अदृश्य बनाने के लिए भी, सीएसएस इसकी अनुमति देता है।

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

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

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

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

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

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

दूसरा समाधान आपके वेब सर्वर के लिए प्रतिक्रिया में x- फ्रेम विकल्प नामक एक HTTP हेडर भेजने के लिए है। इसलिए, जब वेब सर्वर एक प्रतिक्रिया देता है, तो वह इस हेडर को सेट कर सकता है, जो कहेगा: "हे, ब्राउज़र, किसी को भी मेरी सामग्री को फ्रेम के अंदर डालने मत देना!"। यह समाधान ब्राउज़र को प्रवर्तन क्रियाएं करने की अनुमति देता है।

तो यह बहुत आसान है। लेकिन अभी भी अन्य पागल हमलों का एक गुच्छा है जो आप व्यवस्थित कर सकते हैं।

जैसा कि मैंने पहले उल्लेख किया है, तथ्य यह है कि अब हम अंतरराष्ट्रीय इंटरनेट पर रहते हैं एक डोमेन या होस्ट नाम का उपयोग करके समस्याएं पैदा करता है।

मान लीजिए कि हमारे पास पत्र सी है लेकिन किस भाषा में है? लैटिन ASCII से यह पत्र किस वर्णमाला का है या यह सिरिलिक में C है? यह आपको उन हमलों को व्यवस्थित करने की अनुमति देता है जो अलग-अलग व्याख्या और अलग-अलग उपयोग करते हैं, लेकिन स्पष्ट रूप से समान पत्र। उदाहरण के लिए, एक हमलावर cat.com डोमेन नाम पंजीकृत करेगा। और उपयोगकर्ता इस डोमेन पर जाएंगे, यह सोचकर कि वे साइट "कैट। कॉम" पर जाएंगे, लेकिन वास्तव में वे हमलावर "sats.com" की साइट पर पहुंचेंगे, क्योंकि यहां पहला अक्षर लैटिन नहीं है, लेकिन सिरिलिक है।

एक हमलावर डोमेन fcebook.com को पंजीकृत कर सकता है, लेकिन लोग असावधान हैं, वे इसे facebook.com के रूप में लेंगे और वहां जाएंगे। इसलिए यदि आप Facebook.com को नियंत्रित करते हैं, तो आपको उन लोगों से एक टन ट्रैफ़िक मिलेगा, जो सोचते हैं कि वे Facebook में लॉग इन हैं।



विभिन्न प्रकार के विभिन्न प्रकार के हमले होते हैं, जिन्हें आप डोमेन नाम पंजीकरण प्रणाली के माध्यम से लॉन्च कर सकते हैं, जिनके खिलाफ बचाव करना मुश्किल है, क्योंकि आप उपयोगकर्ताओं को टाइपोस बनाने से कैसे रोक सकते हैं? या ब्राउज़र उपयोगकर्ता को कैसे इंगित करता है: "अरे, यह सिरिलिक है, लैटिन नहीं" !?

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

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

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

आखिरी चीज जिस पर मैं चर्चा करना चाहता हूं वह है स्क्रीन शेयरिंग अटैक, या स्क्रीन शेयरिंग अटैक।

HTML5 वास्तव में एक नया एपीआई परिभाषित करता है जिसके द्वारा एक वेब पेज दूसरे ब्राउज़र या सर्वर के साथ साझा करने के लिए अपने सभी बिट्स साझा कर सकता है। यह वास्तव में एक अच्छा विचार है, क्योंकि यह कई उपयोगकर्ताओं के लिए एक ही दस्तावेज़ पर एक साथ काम करना संभव बनाता है। यह महान है क्योंकि हम भविष्य में रहते हैं।

लेकिन सबसे मजेदार बात यह है कि जब उन्होंने इस नए एपीआई को विकसित किया, तो उन्होंने एक आम स्रोत नीति के बारे में बिल्कुल नहीं सोचा!

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



तो, वास्तव में, यह उसी मूल स्रोत की नीति में एक विनाशकारी दोष है, इसलिए आपको इसे ठीक करने पर विचार करना चाहिए। उदाहरण के लिए, यदि सही फ्रेम का कोई व्यक्ति स्क्रीनशॉट लेने की क्षमता रखता है, तो वह केवल सही फ्रेम का स्क्रीनशॉट ले पाएगा, न कि पूरे स्क्रीन को एक पूरे के रूप में।

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

इस व्याख्यान के बारे में छात्रों द्वारा इंटरनेट पर पूछे गए बहुत सारे प्रश्न थे: “डेवलपर्स ने ऐसा क्यों नहीं किया जो वे कर सकते थे? यह स्पष्ट नहीं है? ” या: “ऐसा लगता है कि यह विशेष योजना मृत है। अन्य बेहतर नहीं होगा? " और इसी तरह।

मैं आपको ईमानदारी से बताऊंगा - हाँ, यह सुनिश्चित करने के लिए है, अगर डेवलपर्स जिम्मेदारी से लेते हैं तो लगभग सब कुछ बेहतर होगा। इसलिए मुझे शर्म आती है कि मैं इससे जुड़ा हूं।

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



इसलिए, मैं आपसे उन चीजों पर हमेशा ध्यान देने के लिए कहता हूं, जिन पर हमने आज चर्चा की। कल्पना कीजिए कि अगर हम खरोंच से शुरू करने जा रहे थे, तो हमारे सामने जो कुछ भी था, उसे नष्ट कर दिया और एक बेहतर सुरक्षा नीति के साथ आने की कोशिश की, आप क्या सोचते हैं, हमारे लिए कितनी साइटें काम करेंगी? मुझे लगता है कि 2% से अधिक नहीं। तो उपयोगकर्ता शायद हमारे बारे में शिकायत करेंगे।

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


.

, . ? ? , 30% entry-level , : VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps $20 ? ( RAID1 RAID10, 24 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps , .

Dell R730xd 2 ? 2 Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 $249 ! . c Dell R730xd 5-2650 v4 9000 ?