कैसे केवल कुकीज़ AJAX अनुरोधों के साथ काम करते हैं?




cookies httponly (6)

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

संपादित करें: माइक्रोसॉफ्ट ने XSS हमलों को रोकने के लिए एक तरीका बनाया है यदि कुकीज़ को जावास्क्रिप्ट एक्सेस को अस्वीकार कर दिया गया है तो HttpOnly निर्दिष्ट है। फ़ायरफ़ॉक्स ने बाद में इसे अपनाया। तो मेरा सवाल यह है कि: यदि आप किसी साइट पर AJAX का उपयोग कर रहे हैं, जैसे स्टैक ओवरफ्लो, केवल कुकीज़ ही विकल्प हैं?

2 संपादित करें: प्रश्न 2. यदि एचटीपी का उद्देश्य कुकीज़ पर जावास्क्रिप्ट तक पहुंच को रोकने के लिए है, और आप अभी भी XmlHttpRequest ऑब्जेक्ट के माध्यम से जावास्क्रिप्ट के माध्यम से कुकीज़ पुनर्प्राप्त कर सकते हैं, तो केवल एचटीपी का क्या मतलब है ?

संपादित करें 3: विकिपीडिया से उद्धरण यहां दिया गया है:

जब ब्राउजर को ऐसी कुकी मिलती है, तो इसे सामान्य HTTP एक्सचेंजों में सामान्य रूप से उपयोग करना चाहिए, लेकिन इसे क्लाइंट-साइड स्क्रिप्ट पर दिखाना नहीं है। [32] HttpOnly ध्वज किसी भी मानक का हिस्सा नहीं है, और सभी ब्राउज़रों में लागू नहीं किया गया है। ध्यान दें कि वर्तमान में XMLHTTPRequest के माध्यम से सत्र कुकी पढ़ने या लिखने की कोई रोकथाम नहीं है। [33]।

मैं समझता हूं कि जब आप केवल एचटीपी का उपयोग करते हैं तो document.cookie अवरुद्ध है। लेकिन ऐसा लगता है कि आप XSS के लिए अनुमति देने वाले XMLHttpRequest ऑब्जेक्ट में अभी भी कुकी मान पढ़ सकते हैं। कैसे आपको केवल सुरक्षित से अधिक सुरक्षित बनाता है? कुकीज़ को अनिवार्य रूप से केवल पढ़ने के द्वारा?

आपके उदाहरण में, मैं आपके document.cookie .cookie पर नहीं लिख सकता, लेकिन मैं अभी भी अपनी कुकी चुरा सकता हूं और XMLHttpRequest ऑब्जेक्ट का उपयोग करके इसे अपने डोमेन पर पोस्ट कर सकता हूं।

<script type="text/javascript">
    var req = null;
    try { req = new XMLHttpRequest(); } catch(e) {}
    if (!req) try { req = new ActiveXObject("Msxml2.XMLHTTP"); } catch(e) {}
    if (!req) try { req = new ActiveXObject("Microsoft.XMLHTTP"); } catch(e) {}
    req.open('GET', 'http://stackoverflow.com/', false);
    req.send(null);
    alert(req.getAllResponseHeaders());
</script>

संपादित करें 4: क्षमा करें, मेरा मतलब था कि आप XMLHttpRequest को StackOverflow डोमेन पर भेज सकते हैं, और उसके बाद getAllResponseHeaders () को स्ट्रिंग में सहेज सकते हैं, कुकी को रीगेक्स कर सकते हैं और उसके बाद उसे बाहरी डोमेन पर पोस्ट कर सकते हैं। ऐसा प्रतीत होता है कि विकिपीडिया और हेक्कर इस पर मेरे साथ सहमत हैं, लेकिन मुझे फिर से शिक्षित होना अच्छा लगेगा ...

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

मैंने जो कुछ सीखा है उसे दोहराने के लिए:

  • एचटीपी केवल आईई 7 में document.cookie तक पहुंच को प्रतिबंधित करता है और फ़ायरफ़ॉक्स (अन्य ब्राउज़रों के बारे में निश्चित नहीं है)
  • एचईपी केवल आईई 7 में XMLHttpObject.getAllResponseHeaders () में प्रतिक्रिया शीर्षकों से कुकी जानकारी को हटा देता है।
  • XMLHttpObjects केवल उनके द्वारा उत्पन्न डोमेन पर सबमिट किए जा सकते हैं, इसलिए कुकीज़ का कोई क्रॉस-डोमेन पोस्टिंग नहीं है।

संपादित करें: यह जानकारी अब तक अद्यतित नहीं है।


इसलिए मुझे लगता है कि जावास्क्रिप्ट को आपकी कुकीज़ तक पहुंच की आवश्यकता है।

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

आपके प्रश्न का औपचारिक उत्तर phrased के रूप में - "अगर AJAX का उपयोग किया जाता है तो जावास्क्रिप्ट को कुकीज़ तक पहुंच की आवश्यकता होती है?" - इसलिए "नहीं" है। उदाहरण के लिए ऑटो-सुझाव विकल्प प्रदान करने के लिए अजाक्स अनुरोधों का उपयोग करने वाले उन्नत खोज फ़ील्ड के बारे में सोचें। उस मामले में कुकी जानकारी की कोई ज़रूरत नहीं है।


इसके लिए थोड़ा और है।

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

यह अजीब बात है कि XMLHTTPresponse शीर्षलेख कुकी दे रहे हैं, तकनीकी रूप से सर्वर को प्रतिक्रिया के साथ कुकी को वापस नहीं करना है। एक बार यह ग्राहक पर सेट हो जाने पर, यह समाप्त होने तक सेट रहता है। यद्यपि ऐसी योजनाएं हैं जिनमें पुन: उपयोग को रोकने के लिए प्रत्येक अनुरोध के साथ कुकी बदल दी गई है। तो आप XMLHTTP प्रतिक्रियाओं पर कुकी प्रदान न करने के लिए सर्वर को बदलकर उस कार्यवाही से बचने में सक्षम हो सकते हैं।

सामान्य तौर पर, मुझे लगता है कि HTTP केवल कुछ सावधानी के साथ उपयोग किया जाना चाहिए। क्रॉस साइट स्क्रिप्टिंग हमले हैं जहां एक हमलावर उपयोगकर्ता को किसी अन्य साइट से उत्पन्न एजेक्स-जैसे अनुरोध सबमिट करने की व्यवस्था करता है, सरल पोस्ट फॉर्म का उपयोग करके, XMLHTTP के उपयोग के बिना, और आपके ब्राउज़र की अभी भी सक्रिय कुकी अनुरोध को प्रमाणित करेगी।

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

आम तौर पर HTTP चाहते हैं कि दिलचस्प कारण कुकीज़ को चोरी करने से आपके वेबपृष्ठ पर शामिल तृतीय-पक्ष सामग्री को रोकना है। लेकिन तीसरे पक्ष की सामग्री को शामिल करने के बारे में बहुत सावधान रहने के कई दिलचस्प कारण हैं, और इसे आक्रामक रूप से फ़िल्टर करें।


जरूरी नहीं, यह निर्भर करता है कि आप क्या करना चाहते हैं। क्या आप थोड़ा सा विस्तार कर सकते हैं? AJAX को काम करने के लिए कुकीज़ तक पहुंच की आवश्यकता नहीं है, यह जानकारी निकालने के लिए अपने आप अनुरोध कर सकता है, पेज अनुरोध है कि AJAX कॉल कुकी डेटा तक पहुंच सकता है और बिना किसी जावास्क्रिप्ट को सीधे एक्सेस करने के लिए कॉलिंग स्क्रिप्ट पर भेज सकता है कुकीज़


नहीं, वह पृष्ठ जो AJAX कॉल अनुरोधों के पास कुकीज तक पहुंच है और यह जांचता है कि आप लॉग इन हैं या नहीं।

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


हां, HTTP-केवल कुकीज़ इस कार्यक्षमता के लिए ठीक होंगी। उन्हें अभी भी सर्वर के लिए XmlHttpRequest के अनुरोध के साथ प्रदान किया जाएगा।

स्टैक ओवरफ़्लो के मामले में, कुकीज़ स्वचालित रूप से XmlHttpRequest अनुरोध के हिस्से के रूप में प्रदान की जाती हैं। मुझे स्टैक ओवरफ़्लो प्रमाणीकरण प्रदाता के कार्यान्वयन विवरणों को नहीं पता है, लेकिन वह कुकी डेटा शायद "वोट" नियंत्रक विधि की तुलना में निचले स्तर पर आपकी पहचान को सत्यापित करने के लिए स्वचालित रूप से उपयोग किया जाता है।

अधिक आम तौर पर, AJAX के लिए कुकीज़ की आवश्यकता नहीं होती है। XmlHttpRequest समर्थन (या पुराने ब्राउज़र पर भी iframe remoting) तकनीकी रूप से आवश्यक है।

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

आपके उदाहरण में, मैं आपके दस्तावेज़.cookie पर नहीं लिख सकता, लेकिन मैं अभी भी अपनी कुकी चुरा सकता हूं और XMLHttpRequest ऑब्जेक्ट का उपयोग करके इसे अपने डोमेन पर पोस्ट कर सकता हूं।

XmlHttpRequest क्रॉस-डोमेन अनुरोध नहीं करेगा (बिल्कुल जिस कारण से आप स्पर्श कर रहे हैं)।

आप आम तौर पर आईफ्रेम रीमोटिंग या जेएसओएनपी का उपयोग कर कुकी को अपने डोमेन पर भेजने के लिए स्क्रिप्ट इंजेक्ट कर सकते हैं, लेकिन फिर HTTP-केवल कुकी को फिर से सुरक्षित करता है क्योंकि यह पहुंच योग्य नहीं है।

जब तक आप सर्वर की तरफ .com से समझौता नहीं करते थे, तो आप मेरी कुकी चोरी नहीं कर पाएंगे।

2 संपादित करें: प्रश्न 2. यदि एचटीपीपी का उद्देश्य कुकीज़ पर जावास्क्रिप्ट तक पहुंच को रोकने के लिए है, और आप अभी भी XmlHttpRequest ऑब्जेक्ट के माध्यम से जावास्क्रिप्ट के माध्यम से कुकीज़ पुनर्प्राप्त कर सकते हैं, केवल एचटीपीपी का बिंदु क्या है?

इस परिदृश्य पर विचार करें:

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

HTTP-केवल कुकीज़ के साथ, दूसरा चरण असंभव होगा, जिससे मेरा एक्सएसएस प्रयास हार जाएगा।

संपादित करें 4: क्षमा करें, मेरा मतलब था कि आप XMLHttpRequest को डोमेन पर भेज सकते हैं, और उसके बाद getAllResponseHeaders () को स्ट्रिंग में सहेज सकते हैं, कुकी को रीगेक्स कर सकते हैं और उसके बाद उसे बाहरी डोमेन पर पोस्ट कर सकते हैं। ऐसा प्रतीत होता है कि विकिपीडिया और हेक्कर इस पर मेरे साथ सहमत हैं, लेकिन मुझे फिर से शिक्षित होना अच्छा लगेगा ...

यह सही है। आप अभी भी उस तरह से हाइजैक सत्र कर सकते हैं। यह उन लोगों के झुंड को काफी पतला करता है जो आपके खिलाफ XSS हैक भी सफलतापूर्वक निष्पादित कर सकते हैं।

हालांकि, अगर आप मेरे उदाहरण परिदृश्य पर वापस जाते हैं, तो आप देख सकते हैं कि HTTP-केवल XSS हमलों को सफलतापूर्वक काटता है जो क्लाइंट की कुकीज़ को संशोधित करने पर निर्भर करता है (असामान्य नहीं)।

यह इस तथ्य को उबालता है कि ए) कोई भी सुधार सभी भेद्यता को हल नहीं करेगा और बी) कोई भी प्रणाली पूरी तरह सुरक्षित नहीं होगी। HTTP-केवल XSS के विरुद्ध शोरिंग में एक उपयोगी टूल है।

इसी तरह, हालांकि XmlHttpRequest पर क्रॉस डोमेन प्रतिबंध सभी XSS शोषण को रोकने में 100% सफल नहीं है, फिर भी आप प्रतिबंध को हटाने का कभी भी सपना नहीं देख पाएंगे।


हां, कुकीज़ अजाक्स के लिए बहुत उपयोगी हैं।

अनुरोध यूआरएल में प्रमाणीकरण रखना बुरा अभ्यास है। Google कैश से URL में प्रमाणीकरण टोकन प्राप्त करने के बारे में पिछले सप्ताह एक समाचार वस्तु थी।

नहीं, हमलों को रोकने के लिए कोई रास्ता नहीं है। पुराने ब्राउज़र अभी भी जावास्क्रिप्ट के माध्यम से कुकीज़ तक छोटी पहुंच की अनुमति देते हैं। आप केवल http को बाईपास कर सकते हैं, आदि। जो कुछ भी आप साथ आते हैं उसे पर्याप्त प्रयास के आसपास मिल सकता है। चाल यह सार्थक होने के लिए बहुत अधिक प्रयास करना है।

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





httponly