ब्राउज़र में JWT कहाँ स्टोर करें? CSRF से बचाव कैसे करें?

Question

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

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

1. यदि JWT कुकी में संग्रहीत है, तो मुझे लगता है कि यह कुकी-आधारित प्रमाणीकरण के समान है, सिवाय इसके कि सर्वर को कुकी / टोकन को सत्यापित करने के लिए सत्रों की आवश्यकता नहीं है। यदि कोई विशेष उपाय लागू नहीं किया गया है तो CSRF के बारे में अभी भी जोखिम है। क्या JWT कुकी में संग्रहीत नहीं है?

2. यदि JWT को लोकलस्टोरेज / सेशनस्टोरेज में स्टोर किया जाता है, तो किसी भी कुकी को सीआरएसएफ से बचाने की जरूरत नहीं है। सवाल यह है कि JWT को सर्वर पर कैसे भेजा जाए। मैंने पाया यहाँ HTTP हेडर ajax अनुरोध के द्वारा जेडब्ल्यूटी भेजने के लिए jQuery का उपयोग कर पता चलता है। तो, केवल ajax अनुरोध प्रमाणीकरण कर सकते हैं?

3. इसके अलावा, मुझे JWT भेजने के लिए "प्राधिकरण हेडर" और "बियरर" का उपयोग करने के लिए एक और ब्लॉग शो मिला । मैं उस ब्लॉग के बारे में बात नहीं करता, जिसके बारे में बात करता हूँ। क्या कोई कृपया "प्राधिकरण हेडर" और "बियरर" के बारे में अधिक बता सकता है? क्या यह JWT को सभी अनुरोधों के HTTP हेडर द्वारा प्रेषित करता है? यदि हाँ, तो CSRF के बारे में कैसे?

Answer 1

JWT टोकन लोकप्रिय हैं क्योंकि वे OAuth 2.0 और OpenID कनेक्ट जैसे नए प्राधिकरण और प्रमाणीकरण प्रोटोकॉल में डिफ़ॉल्ट टोकन प्रारूप के रूप में उपयोग किए जाते हैं ।

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

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

बियरर स्कीम का उपयोग अक्सर वेब APIs (REST सेवाओं) की सुरक्षा के लिए किया जाता है, जो AJAX कॉल या मोबाइल ग्राहकों से प्राप्त की जाती हैं।

Comments

@ Timespace7 नहीं, JWT टोकन भी अक्सर देशी ग्राहकों से लिए जाते हैं। OAuth 2.0 में विशेष रूप से देशी (मोबाइल) ग्राहकों को लक्षित करने वाले प्रवाह हैं। वे जो काम नहीं करते हैं, वह है अंतर्निहित ब्राउज़र प्रमाणीकरण (जैसे कुकीज़ या बुनियादी अधिकार।)।

— MvdD

मैं कह रहा हूं कि यदि आपका API केवल प्राधिकरण हेडर से JWT टोकन को पुनर्प्राप्त करता है, तो यह CSRF के लिए असुरक्षित नहीं है। कुकी से टोकन पाने वाली किसी भी साइट या API को CSRF शमन की आवश्यकता है।

— MvdD

क्या इसका मतलब है कि हम प्रभावी रूप से jwt को कुकी में स्टोर कर सकते हैं और यह सुरक्षित होगा यदि हम प्राधिकरण के हेडर में इसके साथ अनुरोध भेजते हैं?

— कैमेरोनोआर

@cameronjroe आप इसे अपने कुकीज़ में स्टोर कर सकते हैं लेकिन केवल तभी जब आप प्रमाणीकरण के लिए अपने कुकीज़ का उपयोग नहीं करते हैं (आप इस मामले में अपने हेडर का उपयोग करते हैं)

— Jaakko

AJAX कॉल भी ब्राउज़र से उत्पन्न होती है। JWT टोकन का उपयोग ज्यादातर वेब ऐप्स को प्रमाणित करने के लिए उपयोग किए जाने वाले वेब एपीआई (डेटा परोसने वाले) बनाम कुकीज़ के लिए किया जाता है (मार्कअप, चित्र, सीएसएस और जावास्क्रिप्ट

— परोसने के लिए

Answer 2

हमें क्लाइंट कंप्यूटर पर JWT को स्टोर करना होगा। अगर हम इसे एक लोकलस्टोरेज / सेशनस्टोरेज में स्टोर करते हैं तो इसे एक्सएसएस के हमले से आसानी से पकड़ा जा सकता है। अगर हम इसे कुकीज में स्टोर करते हैं तो एक हैकर CSRF हमले में इसका इस्तेमाल कर सकता है (इसे पढ़े बिना) और उपयोगकर्ता को प्रतिरूपित करके हमारे एपीआई से संपर्क कर सकता है और कार्रवाई करने या उपयोगकर्ता की ओर से जानकारी प्राप्त करने के लिए अनुरोध भेज सकता है।

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

तो CSRF समस्या को हल करने के लिए, मैं अपने आवेदन में डबल सबमिट कुकीज़ का उपयोग करता हूं।

कुकीज विधि को डबल जमा करें

1. JWT को एक HttpOnly कुकी में स्टोर करें और इसे HTTPS पर स्थानांतरित करने के लिए सुरक्षित मोड में उपयोग करें।

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

3. जबकि ब्राउज़र स्वचालित रूप से आपके डोमेन को अनुरोध के डोमेन के लिए आपूर्ति करेगा, एक उपयोगी सीमा है: एक वेबसाइट पर चल रहा जावास्क्रिप्ट कोड अन्य वेबसाइटों के कुकीज़ को नहीं पढ़ सकता है। हम अपना CSRF समाधान बनाने के लिए इसका लाभ उठा सकते हैं। CSRF हमलों को रोकने के लिए, हमें एक अतिरिक्त जावास्क्रिप्ट पठनीय कुकी बनानी चाहिए, जिसे कहा जाता है: XSRF-TOKEN। यह कुकी तब बनाई जानी चाहिए जब उपयोगकर्ता लॉग इन हो और इसमें एक यादृच्छिक, बिना अनुमान के स्ट्रिंग होना चाहिए। हम निजी दावा के रूप में JWT में भी इस संख्या को बचाते हैं। हर बार जब जावास्क्रिप्ट एप्लिकेशन एक अनुरोध करना चाहता है, तो उसे इस टोकन को पढ़ना होगा और इसे कस्टम HTTP हेडर में भेजना होगा। क्योंकि ये ऑपरेशन (कुकी पढ़ना, हेडर सेट करना) केवल जावास्क्रिप्ट एप्लिकेशन के एक ही डोमेन पर किए जा सकते हैं,

कोणीय जेएस आपके जीवन को आसान बनाता है

सौभाग्य से, मैं अपने मंच में कोणीय जेएस का उपयोग कर रहा हूं और कोणीय सीएसआरएफ टोकन दृष्टिकोण को लागू करता है, जिससे हमारे लिए इसे लागू करना सरल हो जाता है। हर अनुरोध के लिए कि हमारा कोणीय अनुप्रयोग सर्वर से बनता है, कोणीय $httpसेवा इन चीजों को स्वचालित रूप से करेगी:

• वर्तमान डोमेन पर XSRF-TOKEN नामक कुकी की तलाश करें।
• यदि वह कुकी पाई जाती है, तो वह मूल्य पढ़ता है और इसे X-XSRF-TOKEN हैडर के रूप में अनुरोध में जोड़ता है।

इस प्रकार क्लाइंट-साइड कार्यान्वयन आपके लिए स्वचालित रूप से नियंत्रित किया जाता है! हमें XSRF-TOKENसर्वर साइड में वर्तमान डोमेन पर एक कुकी सेट करने की आवश्यकता है और जब हमारे एपीआई को क्लाइंट से कोई कॉल मिलता है, तो उसे X-XSRF-TOKENहेडर की जांच करनी चाहिए और XSRF-TOKENJWT में इसकी तुलना करनी चाहिए । यदि वे मेल खाते हैं, तो उपयोगकर्ता वास्तविक है। अन्यथा, यह एक जाली अनुरोध है और आप इसे अनदेखा कर सकते हैं। यह विधि "डबल सबमिट कुकी" विधि से प्रेरित है।

सावधान

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

चाहे आप अपने JWT को स्टोर करें localStorageया आप अपने XSRF-token को HttpOnly कुकी में न रखें, दोनों को XSS द्वारा आसानी से पकड़ा जा सकता है। यहां तक ​​कि एक HttpOnly कुकी में आपके JWT को XST विधि जैसे उन्नत XSS हमले द्वारा पकड़ा जा सकता है ।

तो डबल सबमिट कुकीज़ विधि के अलावा, आपको हमेशा XSS के खिलाफ सर्वोत्तम प्रथाओं का पालन करना चाहिए जिसमें सामग्री बचाना भी शामिल है। इसका मतलब यह है कि किसी भी निष्पादन योग्य कोड को हटाने से ब्राउज़र को कुछ ऐसा करने का कारण होगा जो आप इसे नहीं चाहते हैं। आमतौर पर इसका मतलब है // <![CDATA[टैग और HTML विशेषताओं को हटाना जो जावास्क्रिप्ट का मूल्यांकन करते हैं।

यहाँ और पढ़ें:

• कोणीय का XSRF: यह कैसे काम करता है
• अपने JWTs को स्टोर करने के लिए कहाँ - कुकीज़ बनाम एचटीएमएल 5 वेब स्टोरेज

Comments

@AranDehkharagani हाँ मुझे लगता है कि यह रिप्ले हमले को रोकता है खासकर अगर आप JWT को बदलते हैं और पिछले JWT को हर बार एपीआई द्वारा उपयोग किए जाने वाले समय में समाप्त करते हैं। इसका मतलब है कि आपका JWT वन-टाइम पासवर्ड (OTP) जैसा हो जाएगा। आप JWT का उपयोग विभिन्न तरीकों से कर सकते हैं, यह इस बात पर निर्भर करता है कि आप अपने प्लेटफ़ॉर्म में सुरक्षा का कितना ध्यान रखते हैं।

— इमान सेदिघी

जैसा कि आपने उल्लेख किया है, यदि कोई वेबसाइट XSS के लिए असुरक्षित है, तो उपयोगकर्ता के शोषण से कुछ समय पहले की बात है। ऐसा लगता है कि हम सुरक्षा में बहुत कम वृद्धि के लिए महत्वपूर्ण जटिलता का व्यापार कर रहे हैं।

— शसून

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

— इमान सेदिघी

@ImanSedighi मैं स्पष्ट नहीं था, एक कुकी में jwt संग्रहीत करके आप जटिलता जोड़ रहे हैं और अब आपको XSRF से बचाव करना होगा। तो क्यों न छोटे जीवन टोकन के साथ स्थानीय भंडारण का उपयोग करें और XSS को रोकने पर ध्यान केंद्रित करें?

— शॉनसन

@Royi Namir: यदि आप $ 10 एसएसएल प्रमाणपत्र का उपयोग करते हैं, तो विंडशार्क द्वारा घूमना चिंता का विषय नहीं होना चाहिए! यदि वेबसाइट की सुरक्षा महत्वपूर्ण है, तो आपको डेटा को एन्क्रिप्ट करना चाहिए और HTTPS प्रोटोकॉल का उपयोग करना चाहिए।

— इमान सेदिघी

Answer 3

JWTs के भंडारण के पूरे मुद्दे पर एक और कोण:

1. JWTs को कभी भी आपके लोकलस्टोरेज में स्टोर नहीं किया जाना चाहिए
2. वास्तव में, उन्हें आपके कुकीज़ में संग्रहीत नहीं किया जाना चाहिए , जब तक कि आप बहुत सख्त सीएसआरएफ सुरक्षा को लागू करने में सक्षम न हों

प्रेरणा के लिए यह चेकआउट करें

• JWT एक id_token के रूप में आपके उपयोगकर्ता क्रेडेंशियल्स की तरह है
• JWT एक access_token के रूप में आपके सत्र टोकन की तरह है

सबसे सुरक्षित विकल्प इन-मेमोरी है । एक गहरी गोता लगाने के लिए इसे चेकआउट करें