डिकोड किया गया JWT क्या साबित करता है

तीन खंड, जिनमें से दो सिर्फ JSON हैं

एक JWT अपने सामान्य रूप में एक JWS है: बिंदुओं द्वारा अलग किए गए तीन Base64url खंड। पहला हेडर है, दूसरा पेलोड है, तीसरा हस्ताक्षर है।

हेडर और पेलोड सामान्य JSON ऑब्जेक्ट हैं जिन्हें Base64url-एन्कोड किया गया है। एन्कोडेड, एन्क्रिप्टेड नहीं. टोकन रखने वाला कोई भी व्यक्ति, बिना किसी कुंजी के, तुरंत दोनों को पढ़ सकता है - यह कोई दोष नहीं है, यह डिज़ाइन है। JWT एक हस्ताक्षरित बयान है, सीलबंद लिफाफा नहीं। हस्ताक्षर इस बात की गारंटी देता है कि कथन में कोई बदलाव नहीं किया गया है; यह इसे निजी रखने के लिए कुछ नहीं करता है।

परिणाम स्पष्ट रूप से बताने योग्य है क्योंकि यह नियमित रूप से छूट जाता है: JWT पेलोड में कभी भी कोई गोपनीय चीज़ न रखें। पासवर्ड नहीं, पूर्ण राष्ट्रीय पहचानकर्ता नहीं, आंतरिक सिस्टम विवरण नहीं। मान लें कि पेलोड सार्वजनिक है, क्योंकि जिसके पास टोकन है, उसके पास यह है।

तीसरा खंड हस्ताक्षर है, जिसकी गणना पहले दो के आधार पर की जाती है। यह एकमात्र हिस्सा है जिसमें कोई सुरक्षा मूल्य होता है, और यह वह हिस्सा है जिसका मूल्यांकन एक डिकोडर नहीं कर सकता है।

डिकोडिंग क्या साबित करती है: कुछ भी नहीं

पूरी गाइड का यही मुद्दा है. JWT को डिकोड करने से दो Base64url स्ट्रिंग्स को JSON में पार्स किया जाता है। यह पुष्टि करता है कि टोकन अच्छी तरह से बना हुआ है। यह इस बात की पुष्टि नहीं करता है कि टोकन असली है, कि इसे "आईएसएस" दावे में नामित पार्टी द्वारा जारी किया गया था, कि दावों को संपादित नहीं किया गया है, या कि यह कभी वैध था।

कोई भी टोकन बना सकता है. कोई भी JWT लें, "भूमिका": "उपयोगकर्ता" को "भूमिका": "व्यवस्थापक" में बदलें, पेलोड को फिर से एन्कोड करें, अंत में किसी भी हस्ताक्षर को स्टेपल करें, और एक डिकोडर आपके संपादित दावों को बिल्कुल उसी आत्मविश्वास से प्रदर्शित करेगा जैसे उसने मूल को प्रदर्शित किया था। इसके पास अंतर जानने का कोई तरीका नहीं है, क्योंकि अंतर की जांच करना एक अलग ऑपरेशन है जिसके लिए एक कुंजी की आवश्यकता होती है जो डिकोडर के पास नहीं होती है।

तो जब एक डिकोडर - यह वाला, या कोई अन्य - आपको "exp: 2026-01-01" दिखाता है, तो यह वास्तव में आपको क्या बता रहा है: इस टोकन में एक दावा है कि यह उस तारीख को समाप्त हो रहा है। उस दावे का कोई मतलब है या नहीं यह पूरी तरह से इस बात पर निर्भर करता है कि हस्ताक्षर वैध है या नहीं, जिसकी जाँच नहीं की गई है।

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

यह टूल सत्यापन की पेशकश क्यों नहीं करता है?

सत्यापन के लिए तीन चीजों की आवश्यकता होती है जो एक वेब पेज में जिम्मेदारी से नहीं हो सकती: जारीकर्ता की कुंजी, पहले से पिन किया गया एल्गोरिदम, और क्या अस्वीकार करना है इसके बारे में एक नीति।

मुख्य बात स्पष्ट समस्या है. HMAC एल्गोरिदम (HS256 और मित्र) के लिए कुंजी एक साझा रहस्य है - वही रहस्य जिसका उपयोग टोकन बनाने के लिए किया जाता है। इसे किसी वेब पेज में चिपकाने का अर्थ है एक क्रेडेंशियल चिपकाना जो वेब पेज में वैध टोकन डाल सकता है। RSA और ECDSA के लिए सार्वजनिक कुंजी गुप्त नहीं है, लेकिन आपको अभी भी सही JWKS एंडपॉइंट से सही कुंजी लाने की आवश्यकता होगी और उस पर भरोसा करना होगा जो आपके पास है।

एल्गोरिथ्म सूक्ष्म समस्या है, और दो प्रसिद्ध हमलों का स्रोत है। पहला है alg: "none": हेडर दावा करता है कि टोकन अहस्ताक्षरित है, और एक सत्यापनकर्ता जो अपने स्वयं के कॉन्फ़िगरेशन के बजाय हेडर का सम्मान करता है, कुछ भी स्वीकार करता है। दूसरा है RS256-to-HS256 भ्रम: हमलावर एक सार्वजनिक कुंजी लेता है - जो परिभाषा के अनुसार, सार्वजनिक है - हेडर को HS256 कहने के लिए बदलता है, और उस सार्वजनिक कुंजी को HMAC रहस्य के रूप में उपयोग करके टोकन पर हस्ताक्षर करता है। एक सत्यापनकर्ता जो टोकन से एल्गोरिदम को पढ़ता है और "कुंजी" को देखता है, उसे मान्य करेगा।

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

उत्पादन टोकन कहीं भी चिपकाए क्यों नहीं?

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

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

सुरक्षित आदत साइटों का सही आकलन करने पर निर्भर नहीं करती। इस उद्देश्य के लिए समाप्त हो चुके टोकन, परीक्षण-पर्यावरण टोकन, या आपके द्वारा बनाए गए टोकन का उपयोग करें। यदि आपने पहले से ही कहीं - कहीं भी - उत्पादन टोकन चिपका दिया है - तो उसे घुमाएँ। निरस्तीकरण सस्ता है; एक घटना नहीं है.

यही बात हस्ताक्षर करने वाली कुंजियों पर अधिक बल के साथ लागू होती है। किसी वेब पेज में HMAC गुप्त या निजी कुंजी टाइप करने का कोई वैध कारण नहीं है, और कोई भी साइट जो आपके टोकन को "सत्यापित" करने के लिए कह रही है, वह टोकन बनाने की क्षमता मांग रही है। यही ठोस कारण है कि इस टूल में कोई सत्यापन सुविधा नहीं है: सुविधा के लिए अनुरोध की आवश्यकता होती है।

उन दावों को पढ़ना जो मायने रखते हैं

RFC 7519 दावा नामों का एक छोटा समूह पंजीकृत करता है। "iss" जारीकर्ता है, "sub" वह विषय है जिसके बारे में टोकन है, "aud" इच्छित दर्शक है, "exp" समाप्ति है, "nbf" प्रारंभिक वैध समय है, "iat" जारी करने का समय है, और "jti" रीप्ले का पता लगाने के लिए एक अद्वितीय ID है। बाकी सब कुछ एप्लिकेशन-विशिष्ट है।

समय के दावे न्यूमेरिकडेट मान हैं: Unix युग के बाद से सेकंड, मिलीसेकंड नहीं। यह लोगों को लगातार परेशान करता है, क्योंकि अधिकांश JavaScript समय मान मिलीसेकंड हैं। एक टोकन जो 1970 में समाप्त होता प्रतीत होता है, उसे आमतौर पर मिलीसेकंड मान दिया जाता है; ऐसा प्रतीत होता है कि जो वर्ष 55000 में समाप्त हो रहा है, उसका आमतौर पर दूसरा मान कहीं न कहीं 1000 से गुणा किया जाता है।

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

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

भरोसा करने वाले सिस्टम के लिए एक छोटी चेकलिस्ट

यदि आप ऐसा कोड लिख रहे हैं जो केवल टोकन का निरीक्षण करने के बजाय टोकन स्वीकार करता है, तो एक सही सत्यापनकर्ता क्या करता है उसका संक्षिप्त संस्करण निम्नलिखित है।

1. किसी भी दावे को पढ़ने से पहले, बैंड से प्राप्त कुंजी से हस्ताक्षर को सत्यापित करें।
2. एल्गोरिथम को अपने स्वयं के कॉन्फ़िगरेशन में पिन करें। इसे कभी भी टोकन हेडर से न पढ़ें। "कोई नहीं" को बिना शर्त अस्वीकार करें।
3. किसी विश्वसनीय घड़ी के सामने "एक्सप" और "एनबीएफ" की जांच करें, तिरछापन के लिए अधिकतम थोड़ी सहनशीलता के साथ।
4. आपके अपेक्षित मानों के विरुद्ध "iss" और "aud" की जाँच करें। किसी अन्य व्यक्ति के लिए बने टोकन पर वैध हस्ताक्षर अभी भी गलत टोकन है।
5. इसे स्वयं असेंबल करने के बजाय अपने प्लेटफ़ॉर्म के लिए एक सत्यापित लाइब्रेरी का उपयोग करें। इस सूची का प्रत्येक आइटम इसमें है क्योंकि कार्यान्वयन गलत हो गया है।
6. टोकन जीवनकाल छोटा रखें, और एक निरस्तीकरण पथ रखें। अल्पकालिक टोकन उस रिसाव की क्षति को सीमित करते हैं जिस पर आपने अभी तक ध्यान नहीं दिया है।

आप जो चिपकाते हैं उसका क्या होता है

• प्रत्येक रूपांतरण, हैश, डिकोड और अंतर आपके ब्राउज़र टैब में चलता है। सर्वर पर कोई इनपुट अपलोड, लॉग या संग्रहीत नहीं किया जाता है, क्योंकि पेज लोड होने के बाद कोई सर्वर शामिल नहीं होता है।
• हैश ब्राउज़र के अपने Web Crypto कार्यान्वयन से आते हैं, और UUID इसके क्रिप्टोग्राफ़िक रूप से सुरक्षित यादृच्छिक जनरेटर से आते हैं। न ही नेटवर्क कॉल शामिल है।
• आपके द्वारा टाइप किया गया कुछ भी स्थानीय संग्रहण या कुकी पर नहीं लिखा जाता है। पेज को पुनः लोड करने से वह ख़ारिज हो जाता है; टैब बंद करने से वह ख़ारिज हो जाता है।
• साइट-व्यापी विश्लेषण केवल कॉन्फ़िगर किए गए कैनोनिकल प्रोडक्शन होस्ट पर चलता है और गोपनीयता नीति में इसका खुलासा किया गया है; स्थानीय और पूर्वावलोकन होस्ट इसे अस्वीकार कर देते हैं। चिपकाए गए मान, टोकन, URL और फ़ाइल सामग्री को ToolAcre के स्वयं के विश्लेषण ईवेंट से बाहर रखा गया है। वर्तमान कॉन्फ़िगरेशन में विज्ञापन अक्षम है.
• उसने कहा: JWT या API कुंजी एक लाइव क्रेडेंशियल है। सुरक्षित आदत यह है कि इसे कभी भी किसी ऐसे वेब पेज पर पेस्ट न करें जिसे आपने नहीं लिखा है, भले ही इसके दावे कितने भी भरोसेमंद हों - इसमें यह भी शामिल है।

प्रश्न

सीमाएँ

• यह टूल केवल डिकोड करता है. यह हस्ताक्षरों को सत्यापित नहीं करता है, और यह एक अनुपलब्ध सुविधा के बजाय एक स्थायी डिज़ाइन निर्णय है - क्यों, इसके लिए ऊपर दी गई गाइड देखें।
• एन्क्रिप्टेड टोकन (JWE, पांच खंड) को कुंजी के बिना बिल्कुल भी डिकोड नहीं किया जा सकता है। टूल उन्हें पहचानता है और रोकता है।
• नेस्टेड JWTs - एक टोकन जिसका पेलोड स्वयं एक टोकन है - स्वचालित रूप से अनरैप नहीं किया जाता है। आंतरिक टोकन को एक अलग चरण के रूप में डिकोड करें।
• RFC 7519 में परिभाषित पंजीकृत सेट से परे दावा अर्थ एप्लिकेशन-विशिष्ट हैं, इसलिए टूल उनकी व्याख्या किए बिना उनके मान दिखाता है।
• यहां दिखाई गई समाप्ति केवल वही दर्शाती है जो टोकन अपने बारे में दावा करता है। वह दावा सार्थक है या नहीं यह उस हस्ताक्षर पर निर्भर करता है जिसकी जाँच यह टूल नहीं करता है।
• 200,000 वर्णों से बड़े टोकन अस्वीकार कर दिए जाते हैं। कोई भी वास्तविक JWT छोटे परिमाण का होता है।