CSRF टोकन स्टेटलेस (= बिना सत्र) प्रमाणीकरण का उपयोग करते समय आवश्यक है?

Question

क्या CSRF प्रोटेक्शन का उपयोग करना आवश्यक है, जब एप्लिकेशन स्टेटलेस प्रमाणीकरण (HMAC जैसी किसी चीज़ का उपयोग करके) पर निर्भर हो?

उदाहरण:

• हम एक ही पृष्ठ एप्लिकेशन मिल गया है (अन्यथा हम एक लिंक पर टोकन संलग्न करने के लिए है: <a href="...?token=xyz">...</a>।

• उपयोगकर्ता स्वयं का उपयोग करके प्रमाणित करता है POST /auth। सफल प्रमाणीकरण पर सर्वर कुछ टोकन लौटाएगा।

• टोकन को एकल पृष्ठ ऐप के अंदर कुछ चर में जावास्क्रिप्ट के माध्यम से संग्रहीत किया जाएगा।

• इस टोकन का उपयोग प्रतिबंधित URL की तरह करने के लिए किया जाएगा /admin।

• टोकन हमेशा HTTP हेडर के अंदर प्रेषित किया जाएगा।

• कोई Http सत्र, और कोई कुकीज़ नहीं है।

जहाँ तक मैं समझता हूँ, वहाँ (?) क्रॉस साइट के हमलों का उपयोग करने की कोई संभावना नहीं होनी चाहिए, क्योंकि ब्राउज़र टोकन को स्टोर नहीं करेगा, और इसलिए यह स्वचालित रूप से इसे सर्वर पर नहीं भेज सकता (कि कुकीज़ का उपयोग करते समय क्या होगा) सत्र)।

क्या मैं कुछ भूल रहा हूँ?

Comments

बेसिक ऑथ के बारे में सावधान रहें। बाकी सत्रों के लिए कई ब्राउज़र स्वचालित रूप से आधारभूत हेडर भेजेंगे। यह मूल स्रोत को CSRF की कुकी के रूप में कमजोर बना सकता है।

— फिलाई

Answer 1

मुझे CSRF के बारे में कुछ जानकारी मिली + प्रमाणीकरण के लिए कोई कुकीज़ का उपयोग करना :

1. https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/
   "चूंकि आप कुकीज़ पर निर्भर नहीं हैं, आपको क्रॉस साइट अनुरोधों से बचाने की आवश्यकता नहीं है"

2. http://angular-tips.com/blog/2014/05/json-web-tokens-introduction/
   "यदि हम कुकीज़ नीचे जाते हैं, तो आपको वास्तव में क्रॉस साइट के अनुरोधों से बचने के लिए CSRF करने की आवश्यकता है। यह कुछ ऐसा है जो हम कर सकते हैं। JWT का उपयोग करते समय भूल जाएं जैसा कि आप देखेंगे। "
   (JWT = जैसन वेब टोकन, स्टेटलेस ऐप के लिए एक टोकन आधारित प्रमाणीकरण)

3. http://www.jamesward.com/2013/05/13/securing-single-page-apps-and-rest-services
   "CSRF जोखिमों को जोखिम में डाले बिना प्रमाणीकरण करने का सबसे आसान तरीका केवल उपयोगकर्ता की पहचान करने के लिए कुकीज़ का उपयोग करने से बचना है। "

4. http://sitr.us/2011/08/26/cookies-are-bad-for-you.html
   "CSRF के साथ सबसे बड़ी समस्या यह है कि कुकीज़ इस प्रकार के हमले के खिलाफ बिल्कुल कोई बचाव नहीं प्रदान करती हैं। यदि आप कुकी प्रमाणीकरण का उपयोग कर रहे हैं। CSRF से बचाव के लिए आपको अतिरिक्त उपाय भी करने चाहिए। आप जो सबसे बुनियादी सावधानी बरत सकते हैं, वह यह सुनिश्चित करना है कि आपका आवेदन GET अनुरोधों के जवाब में कभी भी कोई दुष्प्रभाव न करे। "

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

---

यदि आपको उपयोगकर्ता को याद रखने की आवश्यकता है, तो 2 विकल्प हैं:

1. localStorage: इन-ब्राउज़र की-वैल्यू स्टोर। उपयोगकर्ता द्वारा ब्राउज़र विंडो बंद करने के बाद भी संग्रहीत डेटा उपलब्ध होगा। डेटा अन्य वेबसाइटों द्वारा सुलभ नहीं है, क्योंकि हर साइट का अपना भंडारण होता है।

2. sessionStorage: इसके अलावा ब्राउज़र डेटा स्टोर में। अंतर यह है: जब उपयोगकर्ता ब्राउज़र विंडो को बंद करता है, तो डेटा हटा दिया जाता है। लेकिन यह अभी भी उपयोगी है, अगर आपके वेबएप में कई पेज हैं। तो आप निम्न कार्य कर सकते हैं:

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

(दोनों के लिए यहां देखें: http://www.w3schools.com/html/html5_webstorage.asp )

---

क्या टोकन के लिए कोई आधिकारिक मानक हैं?

JWT (Json Web Token): मुझे लगता है कि यह अभी भी एक मसौदा है, लेकिन यह पहले से ही कई लोगों द्वारा उपयोग किया जाता है और अवधारणा सरल और सुरक्षित दिखती है। (IETF: http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-25 )
बहुत सारे ढांचे के लिए पुस्तकालय भी उपलब्ध हैं। बस इसके लिए google!

Comments

CSRF पर शानदार सारांश! मैं यह नोट करूंगा कि आपके टोकन को लोकलस्टोरेज या सेशनस्टोरेज में स्टोर करना XSS के हमलों के लिए असुरक्षित है और डेटा को पेज पर स्क्रिप्ट्स द्वारा देखा जा सकता है - इसलिए यदि आपके पास सीडीएन से सेवा की गई कोई स्क्रिप्ट है या यदि आपके किसी एक में दुर्भावनापूर्ण कोड है जेएस पुस्तकालयों, वे उन भंडारण स्थानों से टोकन चोरी कर सकते हैं। देखें: stormpath.com/blog/… मुझे लगता है कि कुकी में एक JWT + CSRF टोकन स्टोर करना सबसे सुरक्षित तरीका है, और फिर अनुरोध किए गए हेडर में CSRF टोकन के साथ अपने गणना किए गए JWT को रखें।

— एरोन ग्रे

के बारे में: "सबसे बुनियादी एहतियात जो आप ले सकते हैं, यह सुनिश्चित करना है कि आपका आवेदन कभी भी जीईटी अनुरोधों के जवाब में कोई दुष्प्रभाव नहीं करता है।" क्या CSRF हमले के लिए POST अनुरोध को नकली बनाना संभव है?

— कोस्टा

सर्वर साइड एप्लीकेशन के आधार पर, यह संभव हो सकता है। वेब फ्रेमवर्क हैं, जो कुछ का उपयोग करते हैं http://.../someRestResource?method=POST। तो यह मूल रूप से एक GETअनुरोध है, लेकिन सर्वर एप्लिकेशन इसे एक POSTअनुरोध के रूप में व्याख्या करता है , क्योंकि यह methodHTTP हेडर के बजाय पैरामीटर का उपयोग करने के लिए कॉन्फ़िगर किया गया था । ...सामान्य वेब ब्राउज़रों के बारे में, वे समान-उत्पत्ति-नीति को लागू करते हैं और केवल GETविदेशी सर्वरों के अनुरोधों पर अमल करेंगे । यद्यपि वेब ब्राउज़र उन वेब मानकों (बग, मैलवेयर) को लागू नहीं करता है, तो अनुरोधों को निष्पादित करना संभव हो सकता है । POST

— बेंजामिन एम

इसके अलावा Server Side App: यह अभी भी अनुरोध बॉडी भेजने के लिए संभव नहीं है, क्योंकि आम ब्राउज़र इसे अनुमति नहीं देगा। हालाँकि, यदि सर्वर ऐप अनुमति देता है method=POST, तो यह body={someJson}डिफ़ॉल्ट अनुरोध निकाय को ओवरराइड करने की अनुमति भी दे सकता है। यह वास्तव में खराब एपीआई डिजाइन और बेहद जोखिम भरा है। हालांकि यदि आपका सर्वर ऐप http://...?method=POST&body={someJson}आपको अनुमति देता है कि आपको वास्तव में क्या करना चाहिए, वहां क्या करना है और क्यों और यदि यह आवश्यक है। (मैं 99,9999% मामलों में कहूंगा कि यह आवश्यक नहीं है)। इसके अतिरिक्त ब्राउज़र केवल कुछ किलोबाइट इस तरह भेज सकते हैं।

— बेंजामिन एम

@BenjaminM ने ​​नोटिस किया कि सेम ओरिजिन पॉलिसी केवल javaScript कोड को परिणाम तक पहुँचने से रोकती है, जबकि अनुरोध "अवरुद्ध" होता है, यह वास्तव में सर्वर तक पहुँचता है - jsbin.com/mewaxikuqo/edit?html,js.output मैंने केवल फ़ायरफ़ॉक्स पर यह परीक्षण किया है। लेकिन आप देव उपकरण खोल सकते हैं और देख सकते हैं कि यहां तक ​​कि आपको "क्रॉस-ऑरिजिन रिक्वेस्ट ब्लॉक" प्राप्त होता है, रिमोट सर्वर वास्तव में पूरे अनुरोध को देखता है। यही कारण है कि आपके सभी POST अनुरोधों में आपके पास टोकन या कस्टम हेडर (और यदि संभव हो तो दोनों)

— Yoni Jah

Answer 2

टी एल; डॉ

एक JWT, अगर कुकीज़ के बिना उपयोग किया जाता है, तो CSRF टोकन की आवश्यकता को नकार देता है - लेकिन! JWT को सत्र / लोकलस्टोरेज में संग्रहीत करके, यदि आपकी साइट पर XSS भेद्यता (काफी सामान्य) है, तो अपने JWT और उपयोगकर्ता की पहचान उजागर करें। csrfTokenJWT में एक कुंजी जोड़ना और JWT को कुकी के साथ स्टोर करना बेहतर है secureऔरhttp-only विशेषताओं को सेट करना बेहतर है।

अधिक जानकारी के लिए इस लेख को अच्छे से पढ़ें https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage

आप एक xsrfToken JWT दावे को शामिल करके इस CSRF सुरक्षा को स्टेटलेस बना सकते हैं:

{ "iss": "http://galaxies.com", "exp": 1300819380, "scopes": ["explorer", "solar-harvester", "seller"], "sub": "[e-mail]", "xsrfToken": "d9b9714c-7ac0-42e0-8696-2dae95dbc33e" }

तो आपको स्थानीय स्ट्रॉन्ज / सेशनस्टोर में सीएसआरटॉकेन के साथ-साथ जेडब्ल्यूटी (जो एक http- केवल और सुरक्षित कुकी में संग्रहीत होता है) को स्टोर करने की आवश्यकता होगी। फिर सीएसआरएफ सुरक्षा के लिए, सत्यापित करें कि जेडडब्ल्यूटी में सीएसआरएफ टोकन सबमिट किए गए सीएसआरएफ-टोकन हेडर से मेल खाता है।

Comments

उपयोगकर्ता के एपीआई प्रमाणीकरण के दौरान सीएसआर को टोकन उपयोग से छूट दी जानी चाहिए?

— user805981 21

यह इंगित करने के लायक है (जैसा कि अन्य लोगों ने स्रोत लिंक पर टिप्पणियों में भी उल्लेख किया है) कि कोई भी सीएसआरएफ शमन, जो कुकीज़ का उपयोग करता है, जो http-only या b नहीं हैं) स्थानीय भंडारण में CSRF टोकन को संग्रहीत करता है, XSS के लिए असुरक्षित है। इसका मतलब है कि प्रस्तुत दृष्टिकोण XSS का उपयोग कर हमलावर से JWT को गुप्त रखने में मदद कर सकता है, लेकिन एक हमलावर अभी भी आपके एपीआई पर एक दुर्भावनापूर्ण अनुरोध को निष्पादित करने में सक्षम होगा, क्योंकि वह एक वैध JWT प्रदान करने में सक्षम है (कुकी के माध्यम से, ब्राउज़र धन्यवाद) और CSRF टोकन (स्थानीय भंडारण / कुकी से इंजेक्ट जेएस के माध्यम से पढ़ें)।

— जोहान्स रूडोल्फ

वास्तव में यहां तक ​​कि एक CSRF टोकन भी XSS के इस स्तर पर आपकी रक्षा नहीं कर सकता है, क्योंकि आप मान रहे हैं कि हमलावर लोकलस्टोरेज का उपयोग कर सकता है, जिसका वर्तमान में उपयोग करने का एकमात्र तरीका स्क्रिप्ट स्तर की पहुंच है, जिसे वे वैसे भी CSFF टोकन का रूप ले सकते हैं। ।

— इसका नोटनॉलिड

ऐसा नहीं है कि @JohannesRudolph क्या कह रहा था? जैसे ही आप CSRF टोकन को वेब स्टोरेज / नॉन-http-only कुकी में स्टोर करते हैं, आप XSS हमले के अपने पदचिह्न बढ़ा रहे हैं क्योंकि वे JS के माध्यम से सुलभ हैं।

— अदाम-बेक

यहां कुल विशेषज्ञ नहीं हैं, लेकिन यदि आप अभी भी एक्सएसएस के संपर्क में हैं जैसा कि आप शुरुआत में थे, तो मुझे यकीन नहीं है कि यह हिस्सा जोड़ना बेहतर है ... वास्तव में पकड़ है। संभवतः यह एक हमलावर के लिए CSRF टोकन की पकड़ पाने के लिए थोड़ा (?) अधिक जटिल है, लेकिन अंत में वह अभी भी आपकी ओर से अनुरोध करने में सक्षम है, यहां तक ​​कि वास्तव में जेडब्ल्यूटी टोकन को जाने बिना। क्या वो सही है? धन्यवाद

— superjos