मैसाचुसेट्स इंस्टीट्यूट ऑफ टेक्नोलॉजी। व्याख्यान पाठ्यक्रम # 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 उदाहरण के लिए, Django इन कोण कोष्ठक ले जाएगा, उन्हें HTML रूप में अनुवाद करेगा, और बाकी पात्रों को फिर से करेगा। यही है, यदि कस्टम नाम मान में कोण कोष्ठक, दोहरे उद्धरण और जैसे हैं, तो इन सभी वर्णों को बाहर रखा जाएगा। यह क्लाइंट ब्राउज़र साइड पर HTML कोड के रूप में व्याख्या नहीं की गई सामग्री बना देगा।
तो अब हम जानते हैं कि कुछ क्रॉस-साइट स्क्रिप्टिंग हमलों के खिलाफ यह बहुत विश्वसनीय बचाव नहीं है। कारण, जैसा कि हमने उदाहरण में दिखाया, यह है कि HTML, और CSS और JavaScript के लिए ये व्याकरण इतने जटिल हैं कि वे ब्राउज़र पार्सर को आसानी से भ्रमित कर सकते हैं।
उदाहरण के लिए, हमारे पास एक बहुत ही सामान्य बात है जो Django के ढांचे के भीतर की गई है। तो, आपके पास कुछ div फंक्शन है, और हम इसके लिए एक डायनामिक क्लास सेट करना चाहते हैं। हम कक्षा को var का मान देते हैं, और इसी तरह आगे भी। विचार यह है कि जब Django इस प्रक्रिया करता है, तो उसे यह पता लगाने की आवश्यकता है कि वर्तमान शैली क्या है और फिर इसे यहां पेस्ट करें।
इस मामले में, एक हमलावर इस वर्ग को परिभाषित करने वाला एक स्ट्रिंग बना सकता है, उदाहरण के लिए, "कक्षा 1" लिखता है। इस बिंदु पर सब कुछ ठीक है, क्योंकि यह एक वैध सीएसएस अभिव्यक्ति की तरह लगता है।
लेकिन फिर हमलावर ओनक्लिक ऑपरेटर को यहां रखता है, जो सिस्टम कोड को बनाने वाले जावास्क्रिप्ट कोड के बराबर है।
चूंकि यह गलत है, ब्राउज़र को यहां रुकना चाहिए। लेकिन समस्या यह है कि अगर आपने कभी एक वास्तविक वेब पेज का HTML देखा है, तो सब कुछ टूट गया और भ्रमित हो गया, यहां तक कि वैध, "दोस्ताना" साइटों के लिए भी। इसलिए यदि ब्राउज़र प्रत्येक गलत HTML अभिव्यक्ति से पहले बंद हो जाता है, तो एक भी साइट जिसे आप पसंद करते हैं बस कभी काम नहीं करेगा। यदि आप कभी भी दुनिया में निराश होना चाहते हैं, और मैंने आपकी पर्याप्त मदद नहीं की है, तो साइट को देखते समय अपने ब्राउज़र में जावास्क्रिप्ट कंसोल खोलें, यह देखने के लिए कि यह आपको कितनी त्रुटियां देगा।
उदाहरण के लिए, आप CNN पर जा सकते हैं और बस देख सकते हैं कि आपको कितनी त्रुटियां मिलीं। हां, मूल रूप से सीएनएन काम करता है, लेकिन बहुत असमान रूप से। उदाहरण के लिए, एक्रोबैट रीडर को खोलने के लिए, आपको लगातार अशक्त सूचक अपवादों को फेंकने की आवश्यकता होती है, और साथ ही आप जीवन से थोड़ा धोखा महसूस करेंगे। लेकिन इंटरनेट पर, हमने बहुत आक्रोश के बिना इसे स्वीकार करना सीख लिया है।
इसलिए, चूंकि ब्राउज़र को इस तरह की चीजों के प्रति बहुत सहिष्णु होना चाहिए, इसलिए वे दुर्भावनापूर्ण कोड को ऐसी चीज़ में बदलने की कोशिश करेंगे जो उन्हें उचित लगता है। और वह सुरक्षा भेद्यता है।
यह है कि सामग्री कीटाणुशोधन कैसे काम करती है, और यह अभी भी कुछ नहीं से बेहतर है। वह बहुत सी हानिकारक चीजों को पकड़ सकता है, लेकिन हर चीज से अपना बचाव नहीं कर सकता।
सोचने के लिए एक और चीज है - एक कम अभिव्यंजक मार्कअप भाषा का उपयोग। आइए देखें कि क्या मतलब है।
श्रोता: अगर सामग्री सफाई काम नहीं करती है तो मुझे क्या करना चाहिए?
प्रोफेसर: हाँ, यह संभव है, उदाहरण के लिए, इस मामले में Django सांख्यिकीय रूप से यह निर्धारित करने में सक्षम नहीं होगा कि यह खराब है। उदाहरण के लिए, इस विशेष मामले में। लेकिन इस मामले में जब मैं एक दुर्भावनापूर्ण छवि टैग सम्मिलित करता हूं ...
श्रोता: इस विशेष मामले में, मुझे उम्मीद है कि वर्ग असाइनमेंट उद्धरण चिह्नों में होगा और इस मामले में कोई प्रभाव नहीं होना चाहिए ...
प्रोफेसर: ठीक है, तुम देखो, छोटी चालें हैं। यह मानते हुए कि HTML और CSS के व्याकरण को ध्यान से परिभाषित किया गया है, आप एक ऐसी दुनिया की कल्पना कर सकते हैं जिसमें आदर्श पार्सर किसी तरह इन समस्याओं को पकड़ सकते हैं या किसी तरह उन्हें सामान्य चीजों में बदल सकते हैं। लेकिन वास्तव में, HTML व्याकरण और CSS व्याकरण अशुद्धि से ग्रस्त हैं। इसके अलावा, ब्राउज़र विनिर्देशों को लागू नहीं करते हैं। इसलिए, यदि आप कम अभिव्यंजक व्याकरण का उपयोग करते हैं, तो सामग्री को साफ करना हमारे लिए बहुत आसान होगा।
यहाँ मार्कडाउन शब्द का उपयोग किया जाता है - मार्कअप शब्द के बजाय "मार्कअप पढ़ने में आसान" - सामान्य मार्कअप। मार्कडाउन का मुख्य विचार यह है कि यह एक ऐसी भाषा के रूप में तैयार किया गया है, उदाहरण के लिए, उपयोगकर्ताओं को टिप्पणियां पोस्ट करने की अनुमति देता है, लेकिन इसमें खाली टैग, एपलेट समर्थन और पसंद का उपयोग करने की क्षमता नहीं होती है। इसलिए, मार्कडाउन में वास्तव में व्याकरण की विशिष्ट पहचान करना और फिर इसे लागू करना बहुत आसान है।
पूर्ण भाषा में HTML, CSS और JavaScript की तुलना में सरल भाषा में कीटाणुशोधन बहुत आसान है। और एक तरह से, यह सी कोड और पायथन कोड को समझने के बीच अंतर की तरह है। अधिक अभिव्यंजक भाषा को समझने में वास्तव में एक बड़ा अंतर है। इसलिए, अभिव्यक्ति को सीमित करके, आप अक्सर सुरक्षा में सुधार करते हैं।
क्रॉस-साइट स्क्रिप्टिंग हमलों से बचाने के लिए, सीएसपी, सामग्री सुरक्षा नीति का भी उपयोग किया जाता है। CSP का विचार यह है कि यह वेब सर्वर को अनुमति देता है ...
श्रोता: मैं इस मार्कडाउन भाषा के बारे में जानने के लिए उत्सुक हूँ। क्या सभी ब्राउज़र भाषा पार्सिंग करने में सक्षम हैं?
प्रोफेसर: नहीं, नहीं, नहीं। आप बस विभिन्न प्रकार की भाषाओं को HTML में बदल सकते हैं, लेकिन ब्राउज़र उन्हें उनके मूल रूप में नहीं समझते हैं। दूसरे शब्दों में, आपके पास एक टिप्पणी प्रणाली है, और यह मार्कडाउन का उपयोग करता है। यही है, टिप्पणियां, पृष्ठ पर प्रदर्शित होने से पहले, मार्कडाउन कंपाइलर पर जाती हैं, जो उन्हें HTML प्रारूप में अनुवाद करती हैं।
श्रोता: तो हमेशा मार्कडाउन का इस्तेमाल क्यों नहीं करते?
प्रोफेसर: मार्कडाउन आपको एम्बेडेड एचटीएमएल का उपयोग करने की अनुमति देता है, और जहां तक मुझे पता है, कंपाइलर में इसे अक्षम करने का एक तरीका है। लेकिन मैं इसके बारे में गलत हो सकता है। तथ्य यह है कि सीमित भाषा का उपयोग करना हमेशा संभव नहीं होता है, और हर कोई ऐसा नहीं करना चाहता है।
तो, चलिए चर्चा जारी रखते हैं कि सामग्री सुरक्षा नीति की मदद से सुरक्षा कैसे बढ़ाई जाए। यह नीति सर्वर को वेब ब्राउज़र को यह बताने की अनुमति देती है कि वह उस पृष्ठ पर किस प्रकार की सामग्री लोड कर सकता है जो उसे वापस भेजता है, साथ ही यह सामग्री कहाँ से आनी चाहिए।
उदाहरण के लिए, HTTP प्रतिक्रिया में, सर्वर कुछ इस तरह का उपयोग कर सकता है: इसमें सामग्री - सुरक्षा - नीति शीर्ष लेख शामिल है, डिफ़ॉल्ट स्रोत स्वयं है और इसे * .mydomain.com से डेटा प्राप्त होगा।
ऑपरेटर स्वयं के साथ, सर्वर इंगित करता है कि इस साइट की सामग्री केवल किसी विशेष पृष्ठ या mydomain.com के किसी भी उपडोमेन के डोमेन से आनी चाहिए। इसका मतलब है कि अगर हम foo.com पर सेल्फ बाइंडिंग करते हैं, तो सर्वर इस पेज को ब्राउजर में वापस भेज देगा।
मान लीजिए कि एक क्रॉस-साइट स्क्रिप्टिंग हमला bar.com का लिंक बनाने की कोशिश करता है। इस स्थिति में, ब्राउज़र यह देखेगा कि bar.com स्वयं नहीं है और mydomain.com का डोमेन नहीं है, और आगे इस अनुरोध को नहीं छोड़ेगा। यह एक बहुत शक्तिशाली तंत्र है जहाँ आप अधिक विस्तृत नियंत्रण निर्दिष्ट कर सकते हैं। आप ऐसे पैरामीटर सेट करते हैं जो यह दर्शाते हैं कि आपकी छवियों को इस तरह के स्रोत से आना चाहिए, ऐसे और इतने से स्क्रिप्ट। यह वास्तव में सुविधाजनक है।
इसके अलावा, यह नीति वास्तव में एम्बेडेड जावास्क्रिप्ट को रोकती है, इसलिए आप टैग को खोल नहीं सकते, किसी प्रकार की स्क्रिप्ट लिख सकते हैं, और टैग को बंद कर सकते हैं, क्योंकि जो कुछ भी ब्राउज़र में जा सकता है वह केवल एक सशर्त स्रोत से आना चाहिए। CSP, eval () फ़ंक्शन के तर्क का उपयोग करने जैसी खतरनाक चीज़ों को रोकता है, जो एक वेब पेज को गतिशील रूप से उत्पन्न जावास्क्रिप्ट कोड को निष्पादित करने की अनुमति देता है। इसलिए यदि CSP हैडर सेट है, तो ब्राउज़र eval () को निष्पादित नहीं करेगा।
श्रोता: क्या सभी CSP इससे बचाता है?
प्रोफेसर: नहीं। संसाधनों की एक पूरी सूची है जो इसे वास्तव में संरक्षित करती है, और आप कई अवांछित चीजों के खिलाफ सुरक्षा को कॉन्फ़िगर कर सकते हैं, उदाहरण के लिए, निर्दिष्ट करें कि इसे आउटगोइंग सीएसएस और अन्य चीजों का एक गुच्छा स्वीकार करने की अनुमति है।
श्रोता: लेकिन इसके अलावा () के अलावा और भी चीज़ें हैं जिनसे सुरक्षा को खतरा है?
प्रोफेसर: हाँ, वे मौजूद हैं। इसलिए, सवाल हमेशा सुरक्षा की पूर्णता पर उठता है। इसलिए, उदाहरण के लिए, न केवल eval गतिशील रूप से जावास्क्रिप्ट कोड उत्पन्न कर सकता है। फ़ंक्शंस का एक निर्माता भी है, दिए गए टाइमआउट को कॉल करने के कुछ तरीके हैं, आप लाइन पर जाते हैं और आप इस तरह से कोड का विश्लेषण कर सकते हैं। CSP इन सभी खतरनाक आक्रमण वैक्टरों को निष्क्रिय कर सकता है। लेकिन यह दुर्भावनापूर्ण कारनामों के पूर्ण अलगाव के लिए रामबाण नहीं है।
श्रोता: क्या यह सच है कि सभी आंतरिक लिपियों को पृष्ठ पर जाँचने से रोकने के लिए CSP को कॉन्फ़िगर किया जा सकता है?
प्रोफेसर: हाँ, यह गतिशील रूप से उत्पन्न कोड के निष्पादन को रोकने में मदद करता है, जबकि एम्बेडेड कोड को अनदेखा किया जाना चाहिए। ब्राउज़र को हमेशा स्रोत विशेषता से कोड प्राप्त करना चाहिए। वास्तव में, मुझे नहीं पता कि सभी ब्राउज़र ऐसा करते हैं या नहीं। व्यक्तिगत अनुभव से पता चलता है कि ब्राउज़र विभिन्न व्यवहारों को प्रदर्शित करते हैं।
सामान्य तौर पर, इंटरनेट सुरक्षा प्राकृतिक विज्ञानों के समान है, इसलिए लोग केवल ब्राउज़रों के काम करने के तरीकों के बारे में सिद्धांतों को सामने रखते हैं। और फिर आप देखते हैं कि यह वास्तव में कैसे होता है। और असली तस्वीर निराश कर सकती है, क्योंकि हमें सिखाया जाता है कि एल्गोरिदम, सबूत और पसंद हैं। लेकिन ये ब्राउज़र इतनी बुरी तरह से व्यवहार करते हैं कि उनके काम के परिणाम अप्रत्याशित हैं।
ब्राउज़र डेवलपर्स हमलावरों से एक कदम आगे रहने की कोशिश करते हैं, और व्याख्यान में आगे आप इसके उदाहरण देखेंगे। वास्तव में, सीएसपी एक बहुत अच्छी बात है।
एक और उपयोगी बात यह है कि सर्वर एक्स-कंटेंट-टाइप-ऑप्शंस नामक एक HTTP हेडर सेट कर सकता है, जिसका मूल्य nosniff है।
यह शीर्ष लेख MIME को विज्ञापित सामग्री प्रकार से प्रतिक्रिया को त्यागने से रोकता है, क्योंकि शीर्ष लेख ब्राउज़र को प्रतिक्रिया सामग्री प्रकार को ओवरराइड नहीं करने के लिए कहता है। Nosniff विकल्प के साथ, यदि सर्वर कहता है कि सामग्री टेक्स्ट / html है, तो ब्राउज़र इसे टेक्स्ट / html के रूप में प्रदर्शित करेगा।
सीधे शब्दों में कहें, यह हेडर ब्राउज़र को घोषित सामग्री प्रकार से प्रतिक्रिया को "सूँघने" से रोकता है ताकि ब्राउज़र के कहने पर स्थिति ऐसा न हो: "हाँ, मैंने फ़ाइल एक्सटेंशन और वास्तविक सामग्री के बीच एक बेमेल को सूँघा, इसलिए मैं इस सामग्री को कुछ अन्य समझने योग्य बनाता हूँ। मुझे एक बात यह पता चला है कि आपने अचानक बर्बर लोगों को राज्य की चाबी दे दी थी।
इसलिए, इस हेडर को सेट करके, आप ब्राउज़र को ऐसा कुछ नहीं करने के लिए कह रहे हैं। यह कुछ प्रकार के हमलों के प्रभावों को बहुत कम कर सकता है। यहां क्रॉस-साइट स्क्रिप्टिंग हमलों के लिए कुछ कमजोरियों का संक्षिप्त विवरण दिया गया है।
अब आइए एक और लोकप्रिय हमले वेक्टर - एसक्यूएल को देखें। आपने शायद "एसक्यूएल इंजेक्शन", या एसक्यूएल-इंजेक्शन हमले नामक हमलों के बारे में सुना है। इन हमलों का सार वेबसाइट डेटाबेस का उपयोग करना है। उपयोगकर्ता को दिखाए गए पृष्ठ को गतिशील रूप से बनाने के लिए, डेटाबेस क्वेरीज़ जारी की जाती हैं जो इस आंतरिक सर्वर को जारी की जाती हैं। कल्पना करें कि आपके पास एक विशिष्ट तालिका से सभी मानों का चयन करने का अनुरोध है, जहां उपयोगकर्ता आईडी फ़ील्ड एक संभावित अविश्वसनीय स्रोत से इंटरनेट पर निर्धारित किए गए के बराबर है।
हम सभी जानते हैं कि यह कहानी कैसे समाप्त होगी - यह बहुत बुरी तरह से समाप्त होगी, कोई बचेगा नहीं। क्योंकि एक असत्यापित स्रोत से जो आता है वह बहुत परेशानी कर सकता है। वैकल्पिक रूप से, आप उपयोगकर्ता आईडी को निम्न मान दे सकते हैं: उपयोगकर्ता आईडी = "0; DELETE टेबल ”।
तो यहाँ क्या होगा? असल में, सर्वर डेटाबेस कहेगा: "ठीक है, मैं उपयोगकर्ता आईडी को शून्य पर सेट कर दूंगा, और फिर मैं" डिलीट टेबल "कमांड निष्पादित करूंगा।" और वह यह है, आप कर रहे हैं!
वे कहते हैं कि कुछ साल पहले एक निश्चित वायरल छवि दिखाई दी थी। जर्मनी में कुछ लोगों ने कारों पर लाइसेंस प्लेट लगाई, जिस पर 0 लिखा हुआ था; DELETE टेबल। यह विचार था कि सड़क के कैमरे आपके नंबर को पहचानने के लिए ओसीआर का उपयोग करते हैं, और फिर उस नंबर को डेटाबेस में डालते हैं। सामान्य तौर पर, वोक्सवैगन के लोगों ने अपने नंबर पर दुर्भावनापूर्ण कोड डालकर इस भेद्यता का फायदा उठाने का फैसला किया।
मुझे नहीं पता कि यह काम किया है क्योंकि यह अजीब लगता है। लेकिन मैं यह मानना चाहूंगा कि यह सच है। इसलिए मैं फिर से दोहराता हूं - कीटाणुशोधन का विचार आपकी साइट पर अविश्वसनीय स्रोतों से सामग्री के निष्पादन को रोकना है।
इसलिए, इस तथ्य पर ध्यान दें कि कुछ सरल चीजें हो सकती हैं जो काम नहीं करती हैं जैसा कि उन्हें करना चाहिए। तो, आप सोच सकते हैं: "ठीक है, मैं सिर्फ पंक्ति की शुरुआत में एक और उद्धरण क्यों नहीं डाल सकता हूं और ट्रिपल कोट के बीच संलग्न हमलावर के दुर्भावनापूर्ण कोड के निष्पादन को बाहर करने के लिए एक और"?
यूजर आईडी = '' + यूजर आईडी + ''
लेकिन यह काम नहीं करेगा, क्योंकि एक हमलावर हमेशा हमलावर स्ट्रिंग के अंदर उद्धरण चिह्न डाल सकता है। इसलिए ज्यादातर मामलों में, इस तरह के "हाफ-हैकिंग" से आपको उतनी सुरक्षा नहीं मिलेगी जितनी आप उम्मीद करते हैं।
यहां समाधान यह है कि आपको अपने डेटा को सावधानीपूर्वक एन्क्रिप्ट करने की आवश्यकता है। और एक बार फिर मैं दोहराता हूं कि जब आप एक अविश्वसनीय स्रोत से जानकारी प्राप्त करते हैं, तो इसे सिस्टम में उस रूप में सम्मिलित न करें जिसमें यह है। सुनिश्चित करें कि यह सैंडबॉक्स से बाहर कूद नहीं सकता है यदि आप इसे एक दुर्भावनापूर्ण शोषण करने के लिए वहां डालते हैं।
उदाहरण के लिए, आप कच्चे कॉमा ऑपरेटर के उपयोग को रोकने के लिए एक एस्केप फंक्शन डालना चाहते हैं। ऐसा करने के लिए, कई वेब फ्रेमवर्क, जैसे कि Django, में अंतर्निहित पुस्तकालय हैं जो आपको ऐसी चीजों को रोकने के लिए SQL प्रश्नों से बचने की अनुमति देते हैं। ये चौखटे डेवलपर्स को प्रोत्साहित करते हैं कि वे डेटाबेस से सीधे बातचीत न करें। उदाहरण के लिए, Django खुद को एक उच्च-स्तरीय इंटरफ़ेस प्रदान करता है जो आपको कीटाणुरहित करता है।
लेकिन लोग हमेशा प्रदर्शन की परवाह करते हैं, और कभी-कभी लोग सोचते हैं कि ये वेब फ्रेमवर्क बहुत धीमा है। इसलिए, जैसा कि आप जल्द ही देखेंगे, लोग अभी भी कच्चे SQL क्वेरी करेंगे, जिससे समस्याएं हो सकती हैं।
यदि वेब सर्वर अप्रकाशित छवियों से पथ नामों को स्वीकार करता है तो समस्याएँ हो सकती हैं। कल्पना करें कि आपके सर्वर पर कहीं आप कुछ ऐसा ही कर रहे हैं: "www / images /" + फ़ाइल नाम के साथ खोलें, जहाँ फ़ाइलनाम का प्रतिनिधित्व कुछ इस तरह से किया जाता है ... / ... / ... / ... / / आदि / पासवर्ड।
यही है, आप इस पते पर छवि को एक अविश्वसनीय उपयोगकर्ता फ़ाइल से खोलने का आदेश देते हैं, जो वास्तव में आपको गंभीर रूप से नुकसान पहुंचा सकता है। इस प्रकार, यदि आप एक वेब सर्वर या वेब फ्रेमवर्क का उपयोग करना चाहते हैं, तो आपको इन खतरनाक वर्णों का पता लगाने में सक्षम होना चाहिए और इन कच्चे आदेशों के निष्पादन को रोकने के लिए उनसे बचना चाहिए।
चलो सामग्री कीटाणुशोधन पर चर्चा करने से विराम लेते हैं और कुकीज़ के बारे में थोड़ी बात करते हैं। कुकीज़ उपयोगकर्ता को सर्वर साइड पर मौजूद संसाधनों के एक निश्चित समूह से बांधने के लिए सत्र को प्रबंधित करने का एक बहुत लोकप्रिय तरीका है। Django या Zoobar जैसी बहुत सारी रूपरेखाएँ, जो आपको बाद में मिलेंगी, वास्तव में कुकीज़ के अंदर एक यादृच्छिक सत्र पहचानकर्ता डालती हैं। यह विचार है कि यह सत्र आईडी कुछ प्रकार के सर्वर-साइड टेबल में एक सूचकांक है:
तालिका [सत्र आईडी] = उपयोगकर्ता जानकारी।
यही है, सत्र पहचानकर्ता कुछ उपयोगकर्ता जानकारी के बराबर है। नतीजतन, यह सत्र आईडी और कुकीज़ उनके विस्तार में बहुत संवेदनशील टुकड़े हैं। इस सत्र आईडी प्राप्त करने के लिए कई हमलों में कुकीज़ की चोरी शामिल है। जैसा कि हमने अपने अंतिम व्याख्यान में चर्चा की थी, मूल के समान स्रोत की समान नीति आपको कुछ कुकी चोरी के हमलों के खिलाफ कुछ हद तक मदद कर सकती है। क्योंकि समान मूल नीति पर आधारित नियम हैं जो कुकीज़ के मनमाने ढंग से संशोधन को रोकते हैं।
सूक्ष्मता यह है कि आपको किसी ऐसे व्यक्ति के साथ एक डोमेन या उपडोमेन साझा नहीं करना चाहिए जिस पर आपको भरोसा नहीं है। क्योंकि, जैसा कि हमने पिछले व्याख्यान में कहा था, ऐसे नियम हैं जो एक ही मूल के दो डोमेन या उप-डोमेन को एक-दूसरे की कुकीज़ तक पहुंचने की अनुमति देते हैं। और इसलिए, यदि आप एक डोमेन पर भरोसा करते हैं, जिस पर आपको भरोसा नहीं करना चाहिए, तो यह इन कुकीज़ में सत्र पहचानकर्ता को सीधे सेट करने में सक्षम हो सकता है, जिसकी आप दोनों के पास पहुंच है। यह हमलावर को उपयोगकर्ता को हमलावर की पसंद के सत्र पहचानकर्ता का उपयोग करने के लिए मजबूर करने की अनुमति देगा।
मान लीजिए कि एक हमलावर Gmail उपयोगकर्ता कुकी सेट करता है। एक उपयोगकर्ता जीमेल में लॉग इन करता है और कुछ अक्षर टाइप करता है। एक हमलावर तब इस कुकी का उपयोग कर सकता है, विशेष रूप से, इस सत्र पहचानकर्ता का उपयोग करें, जीमेल डाउनलोड करें, और फिर जीमेल का उपयोग करें जैसे कि वह एक पीड़ित उपयोगकर्ता होगा। इस प्रकार, कई सूक्ष्मताएं हैं जो आप अपने सत्र का प्रबंधन करने के लिए इन कुकीज़ के साथ कर सकते हैं। हम उनमें से कुछ पर आज और बाद के व्याख्यानों में चर्चा करेंगे।
शायद आपको लगता है कि आप सिर्फ कुकीज़ से छुटकारा पा सकते हैं? आखिरकार, वे लाभ की तुलना में अधिक समस्याएं लाते हैं। उन्हें क्यों नहीं छोड़ा जा सकता है?
stateless cookie, « », - , , , .
, , , . , . , , . , , , , .
— MA — Message Authentication Codes, . , . HCK - m. , , K. , , . , , .
, . , stateless cookie, Amazon, , x3. - Amazon, AWS, . – K, – AWS, .
, AWS HTTP, .
, , , :
GET /photos/ cat; .jpg HTTP/1.1, - AWS:
HOST: — - — - — , , :
DATE: Mon, June 4, , , . , ID , , , .
? , 3- .
, String To Sign :
— HTTP, GET;
— MDS;
— , html jpg;
— ;
— , , .
, , HCK MAC. , . , . , . ?
, , , - . Amazon , stateless cookie, MD5 .
, , , cookie, . – , , .
, . , , “HCK, m”.
. GET /photos/ cat; .jpg HTTP/1.1 , , . , , . , ? : «, , , ».
56:15
एमआईटी पाठ्यक्रम "कंप्यूटर सिस्टम सुरक्षा"। 9: « Web-», 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 नीदरलैंड और यूएसए में $ 249 से 100 टीवी है ! इन्फ्रास्ट्रक्चर Bldg का निर्माण कैसे करें के बारे में पढ़ें
। एक पैसा के लिए 9,000 यूरो की लागत डेल R730xd E5-2650 v4 सर्वर का उपयोग कर वर्ग?