2008-08-26 21 views
172

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

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

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

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

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

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

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

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

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

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

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

+0

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

+0

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

उत्तर

3

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

0

नहीं है, पेज कि AJAX कॉल अनुरोध करता है कि क्या जांच करता है कि आप लॉग इन हैं कुकीज़ भी & की पहुंच है।

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

1

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

1

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

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

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

+0

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

1

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

55

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

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

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

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

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

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

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

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

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

  • मैं पेज में यह जावास्क्रिप्ट कोड इंजेक्षन करने के लिए एक अवसर पाते हैं:

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

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

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

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

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

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

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

    +0

    कई ढांचे 'csrf' [कुकीज़ में टोकन] डालते हैं (http://stackoverflow.com/q/20504846/781695)। मुझे लगता है कि AJAX कॉल जिसे 'csrf' चेक की आवश्यकता है, तब तक काम नहीं करेगा जब तक कि आप इसे पुनर्प्राप्त करने के लिए जेएस के लिए एक छिपे हुए HTML तत्व में csrf टोकन नहीं डालते। – Medorator

    2

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

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

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

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

    0

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

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

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

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

    2

    इसके लिए कुछ और है।

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

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

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

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

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

    संबंधित मुद्दे