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


195

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

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

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

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

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

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

आपके उदाहरण में, मैं आपको नहीं लिख सकता document.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 () के परिणाम को एक स्ट्रिंग में सहेजें, कुकी को बाहर निकालें, और उसके बाद किसी बाहरी डोमेन पर पोस्ट करें। ऐसा प्रतीत होता है कि विकिपीडिया और हाकर्स इस पर मेरे साथ रहते हैं, लेकिन मैं फिर से शिक्षित होना पसंद करूंगा ...

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

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

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

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


मैंने आपके उदाहरण को एक ग्रिसेमिक स्क्रिप्ट में फेंक दिया और ऐसा लग रहा है कि एफएफ अब कुकीज़ प्रदर्शित नहीं करता है। उत्कृष्ट शोध और उदाहरण।

हो सकता है कि समान मूल नीति के साथ आप एक ऐसे डोमेन के लिए http अनुरोध नहीं कर सकते हैं जो स्क्रिप्ट में नहीं चल रहा है; हालाँकि, मेरा मानना ​​है कि आप आसानी से window.location का उपयोग करके उपयोगकर्ता को एक पृष्ठ पर पुनर्निर्देशित करके कुकीज़ को पास कर सकते हैं और क्वेरी स्ट्रिंग पैरामीटर के माध्यम से जानकारी को पास कर सकते हैं।
लुका मर्ज़ी

@LucaMarzi " आप एक डोमेन के लिए एक http अनुरोध नहीं कर सकते हैं जो समान स्क्रिप्ट नहीं है " में चल रहा है क्या आप कह रहे हैं कि साइट एक्स में मेजबान वाई से एक छवि शामिल नहीं हो सकती है? (एक विशेषता जिसे मोज़ेक के बाद से सभी ब्राउज़रों द्वारा समर्थित किया गया है?)
उत्सुकता से

जवाबों:


64

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


कई रूपरेखा csrf कुकीज़ में टोकन डालती हैं । मुझे लगता है कि AJAX कॉल की जरूरत है csrfजब तक कि आप चेक को तब तक काम न करें जब तक कि आप जेएस को पुनः प्राप्त करने के लिए एक छिपे हुए HTML तत्व में सीएसआरएफ टोकन नहीं डालते।
उपयोगकर्ता

4

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


4

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

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

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

मुझे वास्तव में HTTP केवल कुकीज़ पसंद है - यह उन मालिकाना ब्राउज़र एक्सटेंशनों में से एक है जो वास्तव में बहुत अच्छा विचार था।


3

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

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

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

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

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

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


1

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


1

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

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

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


XmlHttpRequest कुकीज़ की आवश्यकता है। आपके द्वारा उल्लेखित उन्नत खोज एक लॉगिन पृष्ठ के पीछे हो सकती है। लेकिन जावास्क्रिप्ट को वीएम के लिए कुकी मूल्य को उजागर करने में सक्षम होने की आवश्यकता है या नहीं, यह एक अलग सवाल है।
श्री शाइनी और न्यू 宇 Sh

1

स्पष्टीकरण के रूप में - सर्वर के दृष्टिकोण से, AJAX अनुरोध द्वारा अनुरोधित पृष्ठ अनिवार्य रूप से एक मानक HTTP से अलग नहीं होता है, जो किसी लिंक पर क्लिक करने वाले उपयोगकर्ता द्वारा किया गया अनुरोध होता है। सभी सामान्य अनुरोध गुण: उपयोगकर्ता-एजेंट, आईपी, सत्र, कुकीज़, आदि को सर्वर से पारित किया जाता है।


"सत्र" एक HTTP अवधारणा नहीं है। यह एक उच्च स्तरीय अवधारणा है जो एक ढांचे द्वारा HTTP अवधारणाओं के शीर्ष पर बनाई गई है।
जिज्ञासु

0

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

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


0

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

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

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.