एमआईटी पाठ्यक्रम "कंप्यूटर सिस्टम सुरक्षा"। व्याख्यान 8: नेटवर्क सुरक्षा मॉडल, भाग 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

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

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



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

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

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

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

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

हमारे पास HTTP XML अनुरोध हैं। यह मूल रूप से जावास्क्रिप्ट के लिए अतुल्यकालिक रूप से सर्वर से सामग्री प्राप्त करने का एक तरीका है। आप AJAX - अतुल्यकालिक जावास्क्रिप्ट लाने के HTTP XML अनुरोधों के बारे में भी सुन सकते हैं।

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

हमारे पास सभी प्रकार के मल्टीमीडिया समर्थन हैं, उदाहरण के लिए, एक टैग:

<video> 

एक वेब पेज को फ्लैश एप्लिकेशन का उपयोग किए बिना वीडियो चलाने की अनुमति देता है। यह केवल इस वीडियो को मूल रूप से चला सकता है।



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

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



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

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

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

मान लीजिए कि पृष्ठ में कुछ इस तरह है:

 <script> var x = 'UNTRUSTED'; </script> 

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

श्रोता: आपके पास इस कोड के अंदर कहीं गलत समाप्ति उद्धरण चिह्न हो सकता है जो स्क्रिप्ट लाइन को तोड़ देगा।

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



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



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

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

इसलिए ये स्पेसिफिकेशन्स अस्पष्ट हैं और हमेशा यह नहीं दर्शाते हैं कि असली ब्राउज़र क्या करते हैं। यदि आप इस हॉरर को समझना चाहते हैं, तो आप साइट https://www.quirksmode.org/ पर जा सकते हैं, लेकिन यदि आप खुश रहना चाहते हैं, तो आप बेहतर तरीके से वहां नहीं जा सकते हैं। वहाँ, ये सभी भयानक विसंगतियां जो ब्राउज़र तब करते हैं जब उपयोगकर्ता एक कुंजी दबाता है, उसे वहां प्रलेखित किया जाता है। इस साइट पर आप देख सकते हैं कि क्या होता है।

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

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



उदाहरण के लिए, आप सीएनएन पृष्ठ पर जाते हैं, यह आपको लगता है कि यहां सब कुछ एक टैब पर स्थित है। लेकिन उन दृश्य वस्तुओं में से प्रत्येक जो आप देखते हैं वे वास्तव में किसी और से आ सकते हैं। आइए एक बहुत ही सरल उदाहरण देखें।

मान लीजिए कि हम http://foo.com/index.html पर ऑनलाइन गए। विचाराधीन पृष्ठ किस से मिलकर बनता है?



शीर्ष पर वे विज्ञापन हो सकते हैं जो ads.com से डाउनलोड किए गए हों। एक एनालिटिक्स ब्लॉक, उदाहरण के लिए, google.com से, बाईं ओर स्थित हो सकता है। ये लाइब्रेरी उन लोगों की संख्या पर नज़र रखने के लिए बहुत लोकप्रिय हैं, जिन्होंने इस पेज को डाउनलोड किया है, निगरानी के लिए कि लोग किस लिंक पर क्लिक करते हैं, पेज के किन हिस्सों के साथ बातचीत करने में उनकी दिलचस्पी है और इसी तरह।

दाईं ओर, आपके पास एक और जावास्क्रिप्ट लाइब्रेरी हो सकती है, जो jQuery कहती है, जो cdn.foo.com से आती है। यह foo.com के संचालन के लिए प्रदान की गई कुछ सामग्री है।

GUI में हेरफेर करने के लिए jQuery एक बहुत ही लोकप्रिय पुस्तकालय है, इसलिए jQuery कई साइटों पर उपलब्ध है, हालांकि वे इसे विभिन्न स्थानों से प्राप्त करते हैं। इस पृष्ठ पर आगे आप कुछ HTML पाठ डेटा, उपयोगकर्ता के लिए बटन, पाठ इनपुट क्षेत्र और इतने पर और इतने पर देख सकते हैं। तो यह पृष्ठ पर सिर्फ सादे HTML है।

फिर आप foo.com से अंतर्निहित जावास्क्रिप्ट कोड को देख सकते हैं। उदाहरण के लिए, हमारे पास शीर्ष पर एक उद्घाटन टैग है, और जावास्क्रिप्ट कोड सीधे उनके बीच में एम्बेडेड है। हमारे मामले में, वहाँ है जिसे एम्बेडेड जावास्क्रिप्ट कहा जाता है - यह तस्वीर के ऊपर है।

नीचे दी गई पंक्ति में मैं एक जावास्क्रिप्ट स्क्रिप्ट कहता हूं, जो कि वहां है क्योंकि सामग्री ऐसी चीज के बराबर है जो दूरस्थ सर्वर पर रहती है। इसे ही बाहरी जावास्क्रिप्ट सामग्री परिभाषा कहा जाता है। स्क्रिप्ट और एम्बेडेड कोड एक दूसरे से अलग हैं, और हमारे पेज पर foo.com से अंतर्निहित जावास्क्रिप्ट है।



और एक और चीज जो यहां हो सकती है वह है फ्रेम। एक फ्रेम को एक अलग जावास्क्रिप्ट ब्रह्मांड के रूप में सोचा जा सकता है। यह UNIX प्रक्रिया के समतुल्य है। हो सकता है कि यह फ्रेम facebook.com/likethis.html से आया हो और इसके अंदर हमने फेसबुक से जावास्क्रिप्ट बनाया हो।

इसके अलावा हमारे पास कुछ f.jpeg चित्र हो सकते हैं जो facebook.com से भी आते हैं। तो, यह सब एक एकल टैब की तरह दिखता है, हालांकि इसमें विभिन्न सामग्री शामिल हैं जो संभवतः पूरी तरह से अलग सिद्धांतों पर आधारित हो सकती हैं। इसलिए, आप एक आवेदन के बारे में दिलचस्प सवालों का एक पूरा गुच्छा पूछ सकते हैं जो इस तरह दिखता है।



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

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

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

तो इस HTML के लिए ईवेंट हैंडलर को परिभाषित करने में कौन सक्षम होना चाहिए? सबसे पहले, google.com ऐसा करने में सक्षम होना चाहिए। यह foo.com भी हो सकता है, या नहीं भी हो सकता है।
एक और सवाल, क्या इस फेसबुक फ्रेम को आम, बड़े foo.com फ्रेम से जोड़ता है? फेसबुक फ्रेम HTTPS है, जो कि सुरक्षित है, foo.com HTTP है, यानी एक असुरक्षित कनेक्शन है। तो ये दोनों चीजें कैसे बातचीत कर सकती हैं?

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

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

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

प्रत्येक संसाधन को अपना मूल स्रोत सौंपा गया है, और जावास्क्रिप्ट कोड केवल ऐसे स्रोत तक पहुँच प्राप्त कर सकता है। यह उसी मूल के राजनेताओं द्वारा उपयोग की जाने वाली एक शीर्ष-स्तरीय रणनीति है।

लेकिन शैतान विवरण में है, इसलिए बहुत सारे अपवाद हैं जो हम एक दूसरे में देखेंगे। लेकिन इससे पहले कि हम जारी रखें, आइए परिभाषित करें कि मूल क्या है।
मूल रूप से, उत्पत्ति एक नेटवर्क प्रोटोकॉल आरेख और एक होस्ट नाम प्लस पोर्ट है। उदाहरण के लिए, हमारे पास http: // foo.com/index.html जैसा कुछ हो सकता है।



तो, हमारे नेटवर्क प्रोटोकॉल की योजना HTTP है, होस्ट नाम foo.com है, और पोर्ट 80 है। इस मामले में, पोर्ट निहित है। पोर्ट एक सर्वर-साइड पोर्ट है, जिसका उपयोग उपयोगकर्ता सर्वर से कनेक्ट करने के लिए करता है। इसलिए यदि आप एक HTTP योजना के साथ एक URL देखते हैं जहाँ कोई स्पष्ट रूप से निर्दिष्ट पोर्ट नहीं है, तो यहाँ पोर्ट 80 का उपयोग किया जाता है।

यदि आप https: // foo.com/index.html जैसी किसी चीज़ को देखते हैं, तो इन दोनों पतों में एक ही होस्ट नाम होता है, लेकिन वास्तव में उनकी अलग-अलग योजनाएँ हैं - https बनाम http प्रोटोकॉल। इसके अलावा, पोर्ट 443 अंतर्निहित रूप से यहां मौजूद है, जो सुरक्षित HTTPS प्रोटोकॉल के लिए डिफ़ॉल्ट पोर्ट है। इसलिए ये दोनों URL अलग-अलग मूल के हैं।

अंतिम उदाहरण के रूप में, साइट http: // bar.com:8181 / पर विचार करें ...

स्लैश के बाद दीर्घवृत्त इंगित करता है कि ये चीजें एक ही मूल की राजनीति के संबंध में मायने नहीं रखती हैं, कम से कम इस बहुत ही सरल उदाहरण के संबंध में।
हम देखते हैं कि हमारे पास एक HTTP योजना है, hostname bar.com है, और यहां हमारे पास एक स्पष्ट रूप से निर्दिष्ट पोर्ट है। इस मामले में, यह गैर-मानक पोर्ट 8181 है। वास्तव में, यह उत्पत्ति का स्रोत है। मोटे तौर पर, कोई भी यूनिक्स में एक यूआईडी के रूप में उत्पत्ति के बारे में सोच सकता है, जहां एक फ्रेम को एक प्रक्रिया माना जाता है।

इस प्रकार, एक ही मूल नीति के एक ब्राउज़र के कार्यान्वयन में अंतर्निहित चार मुख्य विचार हैं।

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

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

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

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

तो कुकीज़ एक चीज है जिससे उत्पत्ति के हर स्रोत को जोड़ा जा सकता है। इसके अलावा, आप इन संसाधनों के एक अन्य स्रोत के रूप में DOM दस्तावेज़ ऑब्जेक्ट मॉडल का भंडार समझते हैं। यह एक काफी नया इंटरफ़ेस है, लेकिन यह HTML और XML दस्तावेज़ों को संरचित करने के लिए एक इंटरफ़ेस के रूप में पहले से ही महत्वपूर्ण है।

इस प्रकार, DOM रिपॉजिटरी आपको स्रोत बताने की अनुमति देता है: "मुझे किसी दिए गए कुंजी को संबद्ध करें, जो एक स्ट्रिंग है, इस दिए गए मूल्य के साथ, जो एक स्ट्रिंग भी है"।

उत्पत्ति से संबंधित एक और चीज जावास्क्रिप्ट नामस्थान है। यह नामस्थान यह निर्धारित करता है कि उत्पत्ति के स्रोत के लिए कौन से कार्य और इंटरफेस उपलब्ध हैं।

इनमें से कुछ इंटरफेस में शामिल हैं, उदाहरण के लिए, स्ट्रिंग प्रोटोटाइप और पसंद। तब एप्लिकेशन वास्तव में अन्य सामग्री के साथ जावास्क्रिप्ट नामस्थान को पॉप्युलेट कर सकता है।
डोम ट्री के रूप में अभी भी ऐसी चीज है। जैसा कि आप जानते हैं, DOM का अर्थ है "Document Object Model"। और DOM ट्री अनिवार्य रूप से जावास्क्रिप्ट का उपयोग करते हुए पृष्ठ पर HTML का प्रतिबिंब है।



इस प्रकार, आप कल्पना कर सकते हैं कि DOM ट्री के शीर्ष पर एक HTML नोड है, नीचे हेड मेसेज टैग हेड के लिए एक नोड है और बॉडी मैसेज टैग बॉडी के लिए एक नोड है, और इसी तरह।



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

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

दूसरा विचार यह है कि प्रत्येक फ्रेम अपने URL के लिए उत्पत्ति का स्रोत प्राप्त करता है। जैसा कि मैंने पहले उल्लेख किया है, फ्रेम लगभग यूनिक्स पर प्रक्रिया के समान है। यह एक प्रकार का नामस्थान है जो अन्य विभिन्न संसाधनों का एक समूह लाता है।

तीसरा विचार यह है कि स्क्रिप्ट, या जावास्क्रिप्ट कोड, फ्रेम की उत्पत्ति के स्रोत के अनुरूप अनुमतियों के साथ निष्पादित किए जाते हैं।

इसका मतलब यह है कि जब foo.com bar.com से जावास्क्रिप्ट फ़ाइल आयात करता है, तो जावास्क्रिप्ट फ़ाइल foo.com अनुमतियों के साथ कार्य करने में सक्षम होगी। मोटे तौर पर, यह यूनिक्स दुनिया में क्या होता है जब आप किसी और के घर निर्देशिका से संबंधित एक द्विआधारी फ़ाइल चलाने की जरूरत है के समान है। यह कुछ ऐसा है जिसे आपके विशेषाधिकारों के अनुसार किया जाना चाहिए।

चौथा विचार निष्क्रिय सामग्री है। CSS , , .



, . . , , Google Analytics jQuery foo.com. , cookie, , .

Facebook foo.com, , , . . , . , Post Message. .



Post Message , Facebook , , , foo.com. , foo.com , Facebook , , , .

, JavaScript , Facebook, XML HTTP foo.com, , . - , Facebook.com origin, foo.com, HTML-.

, , , ads.com. , , , . , .

, – , !

तथ्य यह है कि सुरक्षा संबंधी चिंताएँ हैं। यह वह सूक्ष्मता है जो 4 वें विचार में छिपी है।

28:00 मिनट

निरंतरता:

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