मैसाचुसेट्स इंस्टीट्यूट ऑफ टेक्नोलॉजी। व्याख्यान पाठ्यक्रम # 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 श्रोता: तो एक हमलावर को चाबी खोजने से क्या रोकता है? यह गुप्त कुंजी कहाँ स्थित है?
प्रोफेसर: हाँ, यह एक अच्छा सवाल है। ज्यादातर मामलों में, AWS के लिए क्लाइंट कोई ब्राउज़र नहीं है, लेकिन क्लाउड में चलने वाली कुछ वर्चुअल मशीनें हैं। इस प्रकार, आप केवल आभासी मशीनों के बीच संचार देखते हैं। आप यह भी सोच सकते हैं कि उपयोगकर्ता किसी तरह इन लिंक को दे सकते हैं या उन्हें किसी भी तरह HTML में एम्बेड कर सकते हैं। यदि आपके पास HTML या जावास्क्रिप्ट स्रोत कोड के अंदर बोर्ड पर दिखाया गया कुछ है, तो आपके पास ऐसा अनुरोध बनाने के लिए कोड होगा। इसलिए, यदि मैं आपको इनमें से एक चीज प्रदान करता हूं, तो आप मेरी ओर से अनुरोध कर सकते हैं।
श्रोता: क्या सामान्य ग्राहकों के लिए MAC का उपयोग करना संभव है?
प्रोफेसर: सामान्य के लिए - क्या आपका मतलब है ब्राउज़र?
श्रोता: आम उपयोगकर्ताओं के लिए।
प्रोफेसर: तथ्य यह है कि कुंजी वास्तव में कहाँ रहती है, का सवाल एक महत्वपूर्ण है। क्योंकि अगर कुंजी को कुकीज़ के रूप में आसानी से चोरी किया जा सकता है, तो हमने कुछ भी नहीं जीता। इसलिए, कई मामलों में, ये सभी चीजें क्लाउड में कहीं संग्रहीत की जाती हैं और वर्चुअल मशीनों के बीच डेटा का आदान-प्रदान करने के लिए काम करती हैं और सर्वर से सर्वर पर भी क्लाउड में प्रेषित होती हैं। इस प्रकार, एप्लिकेशन डेवलपर VM को लॉन्च करता है, जो AWS में संग्रहीत चीजों के एक समूह का आउटसोर्सिंग करता है।
श्रोता: क्या यहाँ नेटवर्क में देरी की समस्या है, इसलिए हमलावर उपयोगकर्ता के तुरंत बाद ही अनुरोध भेज सकता है और पहुँच भी प्राप्त कर सकता है?
प्रोफेसर: हाँ, यह कहना पर्याप्त है कि कई लोगों ने टाइमस्टैम्प की सुरक्षा के विषय पर शोध प्रबंधों का बचाव किया। लेकिन आप बिलकुल सही हैं, क्योंकि हमने एक नहीं बल्कि क्रूड उदाहरण माना है।
कल्पना कीजिए कि यहां, इस स्ट्रिंग टू साइन उदाहरण में, DATE लाइन पर, हमारे पास "सोमवार, 4 जून" का मूल्य होगा। फिर, अगर किसी तरह हमलावर यह सब हासिल कर सकता है, तो वह उपयोगकर्ता के अनुरोध को दोहरा सकेगा। तथ्य यह है कि AWS आपको इन चीजों की समाप्ति तिथि का उपयोग करने की अनुमति देता है। इस प्रकार, एक चीज जो आप कर सकते हैं, वह है यहां एक्सपायर्स फ़ील्ड को जोड़ना, और हम मान लेंगे कि एक समाप्ति तिथि निर्धारित की गई है।
फिर मैं इस लिंक को अलग-अलग लोगों के झुंड को दे सकता हूं, और सर्वर यह जांच करेगा कि क्या उनके अनुरोध समाप्त हो गए हैं।
श्रोता: भले ही समाप्ति की तारीख केवल २०० मिलीसेकंड हो, लेकिन हमलावर नेटवर्क की निगरानी कर रहा है, वह केवल एक के बजाय अनुरोध की कई प्रतियाँ भेजने में सक्षम होगा।
प्रोफेसर: यह बिल्कुल सच है कि अगर हमलावर नेटवर्क पर हमला करता है और देखता है कि ये चीजें तार द्वारा कैसे प्रसारित होती हैं, और समाप्ति की तारीख में पैंतरेबाज़ी के लिए पर्याप्त जगह है, तो वह निश्चित रूप से यह हमला कर सकता है।
तो यह एक नुकीला तरीका था कि स्टेटलेस कुकीज़ कैसे काम करती हैं। यह एक दिलचस्प सवाल उठाता है: इस प्रकार के कुकीज़ के साथ लॉग आउट करने का क्या मतलब है? इसका उत्तर यह है कि आप वास्तव में बाहर नहीं जा रहे हैं। मेरा मतलब है, आपके पास यह कुंजी है और जब भी आप एक अनुरोध भेजना चाहते हैं, तो आप इसे भेजें। लेकिन सर्वर आपकी कुंजी को रद्द कर सकता है।
मान लीजिए सर्वर ने कुंजी को निरस्त कर दिया। लेकिन आप इनमें से एक GET चीजें बना सकते हैं, और जब आप सर्वर को कोई संदेश भेजेंगे, तो यह कहेगा: "हाँ, मुझे पहले से ही आपकी उपयोगकर्ता आईडी पता है, कुंजी निरस्त कर दी गई है, इसलिए मैंने आपका अनुरोध पूरा नहीं किया है।" हालांकि, बारीकियां हैं, और अगर हम एसएसएल जैसी चीजों के बारे में बात करते हैं, तो किसी व्यक्ति को सशक्त करना उन्हें याद करने की तुलना में बहुत आसान है।
जैसे, कई अन्य चीजें हैं जो आप उपयोग कर सकते हैं यदि आप प्रमाणीकरण को लागू करने के लिए पारंपरिक कुकीज़ से बचना चाहते हैं। उनमें से एक डोम-स्टोरेज का उपयोग है, जिसमें क्लाइंट पक्ष के प्रमाणीकरण के बारे में जानकारी शामिल है। आप कुछ सत्र राज्यों को संग्रहीत करने के लिए DOM रिपॉजिटरी का उपयोग कर सकते हैं जो आमतौर पर कुकीज़ के अंदर रखे जाते हैं।
यदि आप पिछले व्याख्यान से याद करते हैं, तो DOM रिपॉजिटरी उन मूल्यों का एक प्रमुख इंटरफ़ेस है जो ब्राउज़र प्रत्येक स्रोत को प्रदान करता है, यानी ब्राउज़र उन्हें वहां से ले जाता है और उन्हें एक स्ट्रिंग में सम्मिलित करता है।
अच्छी बात यह है कि एक ही मूल की समान नीतियों के बारे में DOM के पास ऐसे मूर्खतापूर्ण नियम नहीं हैं। तो, अगर ये नियमित कुकीज़ थे, तो आप इन सभी उपडोमेन ट्रिक्स और पसंद कर सकते हैं। DOM रिपॉजिटरी वास्तव में सख्ती से एक ही स्रोत से जुड़ा हुआ है, इसलिए आप किसी भी उपडोमेन का विस्तार नहीं कर सकते हैं। इसलिए, उल्का जैसे ढांचे इस भंडारण का उपयोग करते हैं।
लेकिन ध्यान दें कि यदि आप DOM रिपॉजिटरी में ऑथेंटिकेशन जानकारी को सेव करना चाहते हैं, तो आपको इस जानकारी को सर्वर में ट्रांसफर करने के लिए खुद को जावास्क्रिप्ट कोड लिखना होगा, इसे एन्क्रिप्ट करना होगा, इत्यादि। यहां आपको इस मामले में क्या करना है।
उदाहरण के लिए, ग्राहक पक्ष प्रमाणपत्रों का उपयोग कर सकता है, x.509 प्रारूप, जिसमें स्वामी के बारे में जानकारी, एक सार्वजनिक कुंजी, प्रमाणीकरण प्राधिकारी के बारे में जानकारी और इलेक्ट्रॉनिक डिजिटल हस्ताक्षर शामिल हैं। इन प्रमाणपत्रों के बारे में अच्छी बात यह है कि इन चीजों तक पहुँचने के लिए जावास्क्रिप्ट में एक स्पष्ट इंटरफ़ेस नहीं है। तो कुकीज़ के विपरीत, जहां एक ही मूल की नीतिगत त्रुटियों को खोजने के लिए हमेशा एक "हथियारों की दौड़" होती है, प्रमाणपत्रों में इसके लिए एक स्पष्ट जावास्क्रिप्ट इंटरफ़ेस नहीं होता है। इसलिए सुरक्षा के दृष्टिकोण से यह बहुत अच्छा है।
जिन समस्याओं का मैंने संक्षेप में उल्लेख किया है, उनमें से एक और जिसके बारे में हम बाद के व्याख्यानों में विस्तार से चर्चा करेंगे, वह है प्रमाणपत्रों का निरसन। यदि कोई उपयोगकर्ता आपके संगठन को छोड़ देता है, तो आप उससे प्रमाणपत्र कैसे ले सकते हैं? यह काफी जटिल है।
इसके अलावा, ये चीजें उपयोग करने के लिए बहुत सुविधाजनक नहीं हैं, क्योंकि कोई भी आपके द्वारा देखी जाने वाली प्रत्येक साइट के लिए प्रमाण पत्र का एक गुच्छा स्थापित नहीं करना चाहता है। इसलिए, प्रमाणीकरण प्रमाणपत्र बहुत लोकप्रिय नहीं हैं, उन कंपनियों या संगठनों के अपवाद के साथ जो बड़ी जिम्मेदारी के साथ सुरक्षा के लिए जिम्मेदार हैं। इससे कुकीज़ की हमारी चर्चा समाप्त होती है।
अब वेब स्टैक में प्रोटोकॉल भेद्यता के बारे में बात करते हैं। दिलचस्प प्रकार के हमलों में से एक ब्राउज़र घटकों में त्रुटियों का उपयोग करना है, उदाहरण के लिए, जब यूआरएल को पार्स करते हैं। तो URL पार्स करना हमारे लिए परेशानी का कारण कैसे बन सकता है?
मान लीजिए कि हमारे पास उस तरह का एक URL है जहां किसी कारण से अजीब अक्षर अंत में एम्बेडेड हैं:
example.com : 80 @ foo.com।
सवाल यह है कि इस विशेष URL की उत्पत्ति क्या है? फ़्लैश ने सोचा होगा कि मेजबान का नाम example.com है। लेकिन जब ब्राउज़र पते का विश्लेषण करता है, तो वह सोचेगा कि इस मामले में मेजबान की उत्पत्ति foo.com है।
यह बहुत बुरा है, क्योंकि जब हमारे पास दो अलग-अलग संस्थाएं हैं जो एक ही संसाधन की उत्पत्ति के बारे में भ्रमित हैं, तो यह अप्रिय समस्याओं से भरा है।
उदाहरण के लिए, एक फ़्लैश कोड दुर्भावनापूर्ण हो सकता है और example.com से कुछ सामग्री डाउनलोड कर सकता है। यदि शोषण foo.com के साथ पेज में बनाया गया था, तो यह वहां कुछ बुरी चीजें भी कर सकता है। और फिर वह example.com से कुछ कोड लेता है और इसे foo.com की शक्तियों के साथ चलाता है। इन जैसे कई जटिल पार्सिंग नियम जीवन को बहुत कठिन बनाते हैं। यह हर समय होता है।
हमने केवल सामग्री के कीटाणुशोधन की जांच की है, जिसका मुख्य विचार यह है कि यह अक्सर बेहतर होता है जब इस तरह की चीज के लिए सरल पार्सिंग नियम होते हैं। हालाँकि, पूर्वव्यापी रूप से यह करना मुश्किल है, क्योंकि HTML पहले से ही है।
अब आइए मेरे पसंदीदा सुरक्षा भेद्यता के बारे में बात करते हैं - .jar विस्तार के साथ फाइलें, जो एक जावा प्रोग्राम के हिस्से के साथ एक ज़िप संग्रह हैं। ब्राउज़र JAR फाइलें हमले का लक्ष्य बन जाती हैं, मुख्यतः जावा एप्लेट्स। 2007 के आसपास, lifehacker.com नामक एक उत्कृष्ट साइट ने छवियों के अंदर ज़िप फ़ाइलों को एम्बेड करने का तरीका बताया। यह स्पष्ट नहीं है कि आप ऐसा करके किसे छिपाने की कोशिश कर रहे हैं, लेकिन lifehacker.com यह सुनिश्चित करता है कि आप इसे कर सकते हैं।
वे मुख्य रूप से इस तथ्य का उपयोग करते हैं कि अगर आप GIF के रूप में छवि प्रारूपों को देखते हैं, तो, एक नियम के रूप में, पार्सर ऊपर से नीचे तक काम करता है। पहले वह हेडर में जानकारी पाता है, और फिर नीचे स्थित शेष बिट्स को देखता है।
जैसा कि यह निकला, आमतौर पर ज़िप फ़ाइलों में हेरफेर करने वाले प्रोग्राम नीचे से ऊपर की ओर काम करते हैं, यानी छवि पार्सिंग की दिशा के विपरीत। सबसे पहले, वे फ़ाइल के पाद लेख में जानकारी पाते हैं और संग्रह के अंदर क्या खोलते हैं। इस प्रकार, यदि आप एक छवि फ़ाइल रखते हैं जिसमें एक ज़िप संग्रह है, तो यह किसी भी अन्य छवि की तरह, सभी चेक, यहां तक कि फ़्लिकर चेक को भी पास कर देगा, और यह आपके ब्राउज़र में एक छवि के रूप में भी दिखाई देगा।
लेकिन केवल आप छिपे हुए सत्य को जान पाएंगे। केवल आप इस बात से अवगत होंगे कि यदि आप इस फ़ाइल को लेते हैं, तो आप इसे अनज़िप कर सकते हैं और वहां मौजूद जानकारी का उपयोग कर सकते हैं। यह एक सस्ती चाल की तरह लगता है, लेकिन हैकर्स कभी सोते नहीं हैं, वे लगातार हमारे जीवन को बर्बाद करना चाहते हैं। तो वे इस विचार को कैसे लागू करते हैं?
वे समझते हैं कि JAR फाइलें .zip प्रारूप से ली गई हैं। इसका मतलब है कि आप एक GIF एनीमेशन या एक स्थिर छवि बना सकते हैं जिसमें एक JAR फ़ाइल होगी, अर्थात, जावास्क्रिप्ट निष्पादन योग्य कोड, बहुत नीचे।
बाद में, लोगों ने इस हमले के तरीके को GIFAR, आधा GIF, आधा JAR और दोनों हिस्सों को बुराई कहा है। यह कमाल था। जब लोगों ने पहली बार इस तरह के अवसर की खोज की, तो उन्हें यह आश्चर्यजनक लगा, लेकिन यह समझ में नहीं आया कि इसका उपयोग कैसे किया जाए। लेकिन जैसा कि यह निकला, इसके आधार पर निम्नलिखित चीजें की जा सकती हैं।
तो आप यह कैसे कर सकते हैं? आप सिर्फ CAD का इस्तेमाल करें। .Gif, take .jar, सेल्फ-एक्सट्रैक्टिंग आर्काइव - बूम, और GIFAR का उपयोग करके आप पर हमला किया!
तो, एक बार आपके पास यह है, तो आप क्या कर सकते हैं? कुछ संवेदनशील साइटें हैं जो उपयोगकर्ताओं को डेटा प्रदान करने की अनुमति देती हैं, लेकिन डेटा प्रकारों की मनमानी नहीं करती हैं। तो फ़्लिकर या ऐसा कुछ हो सकता है कि आप मनमाने ढंग से ActiveX या किसी अन्य मनमाने ढंग से HTML भेजने की अनुमति न दें। लेकिन आपको चित्र भेजने की अनुमति होगी। इसलिए आप इनमें से किसी एक चीज़ का निर्माण कर सकते हैं और इसे इन गोपनीय साइटों में से किसी एक में जमा कर सकते हैं, जिससे आप चित्र भेज सकते हैं। इस मामले में एक सफल हमला करने के लिए आपको क्या करने की आवश्यकता है?
सबसे पहले, इस "भरवां" छवि को इनमें से किसी एक साइट पर भेजें। दूसरे, मौजूदा कमजोरियों का उपयोग करते हुए, XSS क्रॉस-साइट स्क्रिप्टिंग अटैक विधि का उपयोग करें। ऐसा करने के लिए, आपको एप्लेट सम्मिलित करने की आवश्यकता है, जावास्क्रिप्ट में इस तरह की अभिव्यक्ति लिखते हुए:
यह कोड क्रॉस-साइट स्क्रिप्टिंग भेद्यता का फायदा उठाता है, इसलिए इसे साइट की सामग्री में लॉन्च किया जाएगा। GIFAR मूल चेक को पास करेगा, क्योंकि यह साइट के मूल स्रोत के साथ आता है, इस तथ्य के बावजूद कि यह कोड एक हमलावर द्वारा डाला गया था।
इसलिए, अब हमलावर को मूल की सभी अनुमतियों के साथ पीड़ित की साइट के संदर्भ में इस जावा एप्लेट को चलाने का अवसर मिलता है। और इन चीजों में से एक को वास्तव में जीआईएफ छवि के रूप में सही ढंग से पहचाना जाएगा। लेकिन यहां छिपा हुआ कोड है। आपको याद दिला दूं कि पहले तो ब्राउजर आर्काइव की गई फाइलों को अनपैक कर देता है, इसलिए सबसे पहले वह JAR के हिस्से को लॉन्च करेगा, GIF के ऊपरी हिस्से को नजरअंदाज करेगा। तो यह वास्तव में बहुत अद्भुत है।
इसे ठीक करने के कुछ सरल तरीके हैं। उदाहरण के लिए, आप एप्लेट लोडर का उपयोग कर सकते हैं, जो समझता है कि कोई यादृच्छिक कचरा नहीं होना चाहिए। कई मामलों में, मेटाडेटा जानकारी का उपयोग किया जाता है जो इस संसाधन की लंबाई को दर्शाता है। इस मामले में, लोडर शुरू हो जाएगा, जैसा कि उम्मीद है, ऊपर से, इसकी लंबाई का विश्लेषण करें, देखें कि एप्लेट शीर्ष पर समाप्त होता है, और बंद हो जाता है। वह निचले हिस्से की परवाह नहीं करता है, यह संभव है कि यह 0. भी है। हमारे मामले में, ऐसा लोडर मदद नहीं करेगा, क्योंकि वह निचले, संग्रहीत भाग से अनुरोध को संसाधित करना शुरू कर देगा, और इसे अनदेखा करते हुए ऊपरी के सामने रुक जाएगा।
इसके बारे में मुझे जो पसंद है वह यह है कि यह वास्तव में दिखाता है कि इंटरनेट सॉफ्टवेयर स्टैक कितना चौड़ा है। सिर्फ इन दो प्रारूपों, GIF और JAR को लेते हुए, आप वास्तव में बुरा हमला कर सकते हैं।
आप पीडीएफ फाइलों के साथ भी ऐसा कर सकते हैं। आप GIF के बजाय पीडीएफ डाल सकते हैं और इस हमले को पीडीएफएआर के खतरों के बारे में कुछ कह सकते हैं। लेकिन अंत में, लोगों ने इस समस्या का पता लगाया, और इस तरह की कमजोरियां अब समाप्त हो गई हैं।
श्रोता: आप इस तरह के हमले के साथ क्या कर सकते हैं, जो एक नियमित XSS क्रॉस-साइट स्क्रिप्टिंग हमले के साथ नहीं किया जा सकता है?
प्रोफेसर: यह एक अच्छा सवाल है। तो इसके बारे में क्या अच्छा है कि जावा अक्सर नियमित जावास्क्रिप्ट की तुलना में अधिक शक्तिशाली उपकरण हो सकता है, क्योंकि यह थोड़ा अलग नियम, एक ही मूल नीति और इसी तरह का उपयोग करता है। लेकिन आप सही हैं कि यदि आप क्रॉस-साइट स्क्रिप्टिंग चला सकते हैं, तो जावास्क्रिप्ट को चलाना आपके लिए बहुत हानिकारक हो सकता है। लेकिन इस पद्धति का मुख्य लाभ यह है कि यह हमला तकनीक एप्लेट के अंदर काम करता है और वह कर सकता है जो साधारण दुर्भावनापूर्ण स्क्रिप्ट कोड के साथ करने में असमर्थ है।
इसलिए, जैसा कि मैंने कहा, यह मेरा अब तक का सबसे पसंदीदा हमला है, इसका मुख्य कारण यह है कि कंप्यूटर के प्रतिष्ठित लोगों ने GIFAR जैसे शब्द के बारे में सोचा।
एक और दिलचस्प बात समय-आधारित हमलों का उपयोग है। आमतौर पर लोग समय को एक संसाधन के रूप में नहीं मानते हैं, जो हमलों के लिए एक वेक्टर हो सकता है। लेकिन जैसा कि मैंने कुछ मिनट पहले उल्लेख किया था, वह समय वास्तव में सिस्टम में एक कारनामे को पेश करने का एक साधन हो सकता है।
जिस विशिष्ट हमले के बारे में मैं आपके साथ बात करने जा रहा हूं वह है गुप्त चैनल हमला। इस हमले का विचार यह है कि एक हमलावर दो अनुप्रयोगों के बीच सूचना का आदान-प्रदान करने का एक तरीका ढूंढता है, और यह विनिमय ऑपरेशन अधिकृत नहीं है। एक हमलावर किसी तरह दो अलग-अलग संसाधनों के बीच बिट्स को स्थानांतरित करने के लिए सिस्टम के कुछ हिस्से का उपयोग कर रहा है।
ऐसी चीज़ का एक अच्छा उदाहरण एक सूँघने वाला सीएसएस हमला है। इस तरह का हमला क्या है?
मान लीजिए कि एक हमलावर के पास एक वेबसाइट है जो एक उपयोगकर्ता देख सकता है। किसी उपयोगकर्ता की वेबसाइट पर जाना वास्तव में काफी सरल है। आप एक विज्ञापन बनाते हैं या फ़िशिंग ईमेल भेजते हैं।
इस प्रकार, हमलावर के पास एक वेबसाइट है जो उपयोगकर्ता का दौरा करती है। और हमलावर का लक्ष्य यह पता लगाना है कि उपयोगकर्ता ने किन अन्य साइटों का दौरा किया है। एक हमलावर कई कारणों से यह जानना चाह सकता है। शायद वह उपयोगकर्ता के खोज प्रश्नों में रुचि रखता है, या वह यह पता लगाने की कोशिश कर रहा है कि यह व्यक्ति कहाँ काम करता है, या शायद वह जानना चाहता है कि क्या यह व्यक्ति कुछ "शर्मनाक" साइटों पर जा रहा है।
एक हमलावर यह कैसे करने जा रहा है यदि केवल एक चीज जिसे वह नियंत्रित करता है वह एक वेबसाइट है जिसे वह किसी उपयोगकर्ता को यात्रा करने के लिए राजी करना चाहता है? एक संभव तरीका लिंक रंगों का उपयोग करना है। जैसा कि आप जानते हैं, यदि आपने एक बार एक लिंक का अनुसरण किया है, तो अगली बार यह आपके ब्राउज़र में एक अलग रंग में दिखाई देता है, यह दर्शाता है कि आपने इस लिंक पर पहले ही बदलाव कर दिया है। यह वास्तव में एक सुरक्षा भेद्यता है।
क्योंकि इसका मतलब है कि आपकी साइट पर, एक हमलावर संभावित URL की एक विशाल सूची बना सकता है जिसे आप देख सकते हैं, और फिर जावास्क्रिप्ट का उपयोग करके देख सकते हैं कि इन URL ने किस रंग का अधिग्रहण किया है। और यदि URL लिंक का रंग बैंगनी है, तो इसका मतलब है कि आप इस साइट पर गए हैं। तो यह एक सुंदर सूक्ष्म चाल है।
दिलचस्प बात यह है कि कई मामलों में आपको URL प्रदर्शित करने की भी आवश्यकता नहीं है। आप डोमिनोज़ प्रकार के अनुसार स्क्रीन पर हेडिंग के रूप में लिंक को व्यवस्थित कर सकते हैं, और यदि उपयोगकर्ता इस लिंक का उपयोग करते हैं तो ये हेडर रंग बदल देंगे। शायद आपको लगता है कि उपयोगकर्ता द्वारा देखी गई साइटों के इन सभी यूआरएल को क्रॉल करना बहुत कठिन है। लेकिन पता सूची के माध्यम से कई फ़िल्टर्ड मार्ग का उपयोग करके इस प्रक्रिया को अनुकूलित किया जा सकता है। उदाहरण के लिए, आप पहले देख सकते हैं कि उपयोगकर्ता ने शीर्ष-स्तरीय URL - cnn.com, Facebook.com, इत्यादि का दौरा किया है या नहीं। यदि उत्तर हां है, तो आप सबसे अधिक देखे गए शीर्ष-स्तरीय पृष्ठों का चयन कर सकते हैं। इस तरह आप वास्तव में अपनी खोज को सीमित कर सकते हैं।
तो हानिरहित फ़ंक्शन जो ब्राउज़र उपयोगकर्ता की मदद करने के लिए समर्थन करता है, कह रहा है: "अरे, दोस्त, यह वह जगह है जहाँ आप गए थे!" एक हमलावर द्वारा आप पर सबूत के रूप में इस्तेमाल किया जा सकता है।
मैं एक गुप्त चैनल हमले को कैसे रोक सकता हूं? व्यवहार में, ऐसा किया जाता है कि ब्राउज़र लिंक के सही रंग के बारे में केवल जावास्क्रिप्ट को मूर्ख बनाता है। JavaScript , , . , . , , JavaScript , . , , ? , .
, , — . – , .
, , . , , .
, — , , , , , . , , , , . ?
, . . , .
, Google Map Tiles. , «» Google Map, , , , . .
? , . , , , . , .
, , , JavaScript . , , DNS.
: , , DNS , . , , -, , -. , , DNS . , , DNS , .
: JavaScript .
: , !
: , , , , ?
: , . , — - , , , - URL. , API– , .
: - , , ?
: . , API — . , ? , DNS , .
, , IP — ? ! , JavaScript . . , , ! .
, URL-, .
<iframe>, , , , , , , , <iframe>. <iframe> , , <iframe> . , origin, .
इस प्रकार, हमलावर अब कुछ भी नहीं छू सकता है और निष्कर्ष निकाल सकता है कि वह उस साइट को निर्धारित करने में सक्षम था जिसे आपने पहले दौरा किया था।
अगले व्याख्यान में मिलते हैं!
पाठ्यक्रम का पूरा संस्करण
यहां उपलब्ध
है ।
हमारे साथ बने रहने के लिए धन्यवाद। क्या आप हमारे लेख पसंद करते हैं? अधिक दिलचस्प सामग्री देखना चाहते हैं? एक आदेश रखकर या अपने दोस्तों को इसकी अनुशंसा करके हमें समर्थन दें,
एंट्री-लेवल सर्वरों के अनूठे एनालॉग पर हैबर उपयोगकर्ताओं के लिए 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 सर्वर का उपयोग कर वर्ग?