क्या JWT को लोकलस्टोरेज या कुकी में स्टोर किया जाना चाहिए? [डुप्लिकेट]

Question

JWT का उपयोग करके REST API सुरक्षित करने के उद्देश्य से, कुछ सामग्रियों (जैसे यह मार्गदर्शिका और यह प्रश्न ) के अनुसार, JWT को स्थानीयस्टोरेज या कुकीज़ में संग्रहीत किया जा सकता है । मेरी समझ के आधार पर:

• LocalStorage XSS के अधीन है और आमतौर पर इसमें किसी भी संवेदनशील जानकारी को संग्रहीत करने की अनुशंसा नहीं की जाती है।
• कुकीज़ के साथ हम झंडा "httpOnly" लगा सकते हैं जो XSS के जोखिम को कम करता है। हालाँकि अगर हम बैकएंड पर कुकीज़ से JWT को पढ़ना चाहते हैं, तो हमें CSRF के अधीन होना चाहिए।

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

क्या मेरी समझ सही है? यदि हां, तो क्या उपरोक्त दृष्टिकोण से कोई सुरक्षा चिंता है? या वास्तव में हम पहले स्थान पर लोकलस्टोरेज का उपयोग करके दूर हो सकते हैं?

Comments

इसे देखें: cryto.net/~joepie91/blog/2016/06/13/stop-use-jwt-for-session

— corlaez

@ lrn2prgrm के रूप में एक (स्टेटलेस) JWT और (स्टेटफुल) सत्र शब्दार्थ को एक साथ उपयोग नहीं करना चाहिए ।

— ओजन्मुयेस

Answer 1

मुझे XSRF डबल सबमिट कूकीज विधि पसंद है जिसने उस लेख में उल्लेख किया है जो @ pkid169 ने कहा था, लेकिन एक बात यह है कि लेख आपको पसंद नहीं करता है। आप अभी भी XSS के खिलाफ सुरक्षित नहीं हैं क्योंकि हमलावर क्या कर सकता है वह स्क्रिप्ट है जो आपके CSRF कुकी (जो कि HttpOnly नहीं है) को पढ़ता है और फिर JWT कुकी को स्वचालित रूप से भेजे जा रहे इस CSRF टोकन का उपयोग करके अपने किसी API समापन बिंदु से अनुरोध करें।

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

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

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

Comments

क्या आप स्पष्ट कर सकते हैं कि HttpOnly कुकी में JWT को कैसे पकड़ा जा सकता है? इसका उपयोग एक्सएसआरएफ द्वारा किया जा सकता है अगर एक्सएसआरएफ टोकन एक्सएसएस द्वारा समझौता किया जाता है, लेकिन क्या यह वास्तव में खुद को पकड़ा जा सकता है?

— जेसेक गोर्गो

मुझे पता है कि यह एक पुरानी पोस्ट है, लेकिन मैं कुछ प्रश्न पूछना चाहूंगा ... क्या इसका मतलब यह है कि अच्छी तरह से तैयार की गई स्क्रिप्ट लोकलस्टोरेज और कुकी दोनों को पढ़ सकती है? यदि ऐसा है, तो क्या यह मान लेना सुरक्षित है कि JWT संभवतः किसी भी मामले में चुराया जा सकता है जहां हम इसे एक ब्राउज़र में संग्रहीत करते हैं? फिर, मुझे लगता है कि पूरी तरह से JWT पर निर्भर रहना बहुत जोखिम भरा है।

— हिरोकी

"यहां तक ​​कि HttpOnly कुकी में आपका JWT एक उन्नत XSS हमले द्वारा पकड़ा जा सकता है।" गलत है। इसे ठीक करने के लिए मूल पोस्ट का संपादन किया।

— जावा-आदी ३०१०

"यहां तक ​​कि HttpOnly कुकी में आपके JWT को एक उन्नत XSS हमले द्वारा पकड़ा जा सकता है" मैं सोच सकता हूं कि कोई व्यक्ति कुकी को अपने सर्वर पर भेजकर पकड़ लेता है। उसके लिए वह क्रेडेंशियल ध्वज के उचित मूल्य के साथ भ्रूण का उपयोग कर सकता है। यहां मुख्य समस्या कॉर्सेस सुरक्षा है लेकिन कुछ परिस्थितियों में मुझे लगता है कि यह संभव है।

— bartnikiewi.cz

"वह स्क्रिप्ट जो आपके CSRF कुकी (जो HttpOnly नहीं है) को पढ़ता है" इंजेक्षन करें Html.AntiForgeryToken()। ASP.NET MVC में डिफ़ॉल्ट कार्यान्वयन CSRF टोकन के लिए एक HttpOnly कुकी का उपयोग करता है। मुझे लगता है कि आप अभी भी कुछ एक्सएसएस के लिए अतिसंवेदनशील हैं, लेकिन यह ध्यान देने योग्य था।

— लवथेनकेडगंज

Answer 2

स्टॉर्मपाथ के एक समय पर पोस्ट ने मेरे बिंदुओं को बहुत विस्तृत किया और मेरे प्रश्न का उत्तर दिया।

टी एल; डॉ

JWT को कुकीज में स्टोर करें, या तो मैंने जो भी उल्लेख किया है, उस तरह से प्राधिकरण के हेडर में JWT पास करें, या जैसा कि लेख बताता है, CSRF को रोकने के लिए बैकएंड पर भरोसा करें (जैसे xsrfTokenकोणीय के मामले में उपयोग करना )।

Comments

हैलो, मुझे यकीन नहीं है कि यह सही है लेकिन, क्या jwt को स्टोर करने के लिए कुकीज़ का उपयोग करने के कुछ विशेष नुकसान हैं जब आप अपने नियंत्रकों के लिए क्रॉसऑरिजिन को लागू कर रहे हैं, तो यह एक ऐसा दृश्य है जहां मेरा सर्वर ऐप एक अलग स्थान पर स्थित है और हम कॉल कर रहे हैं हमारे क्लाइंट ऐप में इसे एपि से जो दूसरे शहर में स्थित है? क्यों नहीं कई webservice प्रदाताओं कुकीज़ का उपयोग करने से बचना चाहिए?

— वलीक

CrossOrigin का मतलब भौतिक स्थानों से नहीं है। यह अन्य डोमेन से आने वाले अनुरोधों को संदर्भित करता है। जब आप कॉर्स का उपयोग करने का निर्णय लेते हैं, तो इननेट कोर आप निर्दिष्ट करते हैं कि आप किस डोमेन की अनुमति देने जा रहे हैं; आप किस हेडर की अनुमति देंगे, आदि

— ब्रायन एलन वेस्ट

Answer 3

• अपने टोकन को लोकलस्टोरेज या सेशनस्टोरेज में स्टोर न करें, क्योंकि इस तरह के टोकन को जावास्क्रिप्ट से पढ़ा जा सकता है और इसलिए यह XSS हमले के लिए अचूक है।
• कुकी में अपना टोकन स्टोर न करें। कुकी (HttpOnly ध्वज के साथ) एक बेहतर विकल्प है - यह XSS प्रवण है, लेकिन यह CSRF हमले के लिए अचूक है

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

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

मैं भी इस लेख को पढ़ने की जोरदार सलाह देता हूं: https://hasura.io/blog/best-practices-of-use-jwt-with-graphql/

Comments

क्यों जोड़ा जटिलता जब आप सिर्फ एक पहुंच टोकन के रूप में ताज़ा टोकन का इलाज कर सकते हैं? कैसे इस दृष्टिकोण अधिक मैं अपने जैसी टोकन चिह्नित दिया सुरक्षित है secure, samesite: strict, http-only?

— चार्मिंग रोबोट

यह अधिक सुरक्षित नहीं है

— क्रिस हॉक्स

Answer 4

CSRF हमलों को रोकने में मदद करने के लिए जो मौजूदा कुकीज़ का लाभ उठाते हैं, आप अपने कुकी को SameSiteनिर्देश के साथ सेट कर सकते हैं । इसे सेट करें laxया strict।

यह अभी भी एक मसौदा है और 2019 तक सभी वर्तमान ब्राउज़रों द्वारा पूरी तरह से समर्थित नहीं है , लेकिन आपके उपयोगकर्ता द्वारा उपयोग किए जाने वाले ब्राउज़र पर आपके डेटा और / या आपके नियंत्रण की संवेदनशीलता के आधार पर, यह एक व्यवहार्य विकल्प हो सकता है। निर्देश के साथ सेट SameSite=laxकरने से "शीर्ष-स्तरीय नौवहन की अनुमति मिलेगी जो 'सुरक्षित' ... HTTP विधि का उपयोग करते हैं।"