डेवलपर टूल · JWT डिकोडर
एल्ग: कोई नहीं हमला और मुख्य भ्रम: सत्यापनकर्ताओं को एल्गोरिदम पिन क्यों करना चाहिए
· यह क्यों मायने रखती है
जेडब्ल्यूटी सुरक्षा क्रिप्टोग्राफी
यदि कोई सत्यापनकर्ता टोकन को अपना स्वयं का एल्गोरिदम चुनने देता है, तो एक हमलावर कोई भी नहीं चुन सकता है या HMAC के लिए RSA को स्वैप कर सकता है। यह पोस्ट हमलों और उन्हें रोकने वाले नियम दोनों की व्याख्या करती है।
वह टोकन जिसने स्वयं को सत्यापित किया - कैसे एक हेडर फ़ील्ड एक हमले की सतह बन गई
एक एल्गोरिदम लेबल हमलावर-नियंत्रित टोकन इनपुट के अंदर बैठता है। यदि कोई सत्यापनकर्ता उस लेबल को किसी भी उपलब्ध सत्यापन मोड का चयन करने की अनुमति के रूप में मानता है, तो टोकन स्वयं को आंकने के लिए उपयोग किए जाने वाले नियम को प्रभावित करना शुरू कर देता है। ToolAcre लेबल को सटीक रूप से उजागर करता है ताकि समीक्षक इसे देख सकें, लेकिन कभी भी क्रिप्टोग्राफ़िक रूप से इस पर कार्य नहीं करता है।
सुरक्षित दिशा इसके विपरीत है: विश्वसनीय सेवा कॉन्फ़िगरेशन स्वीकार्य एल्गोरिदम परिवारों और संबंधित कुंजियों को परिभाषित करता है, फिर आने वाले हेडर को उस नीति से मेल खाना चाहिए। एक डिकोड पैनल उस नीति की आपूर्ति नहीं कर सकता है और इसे केवल सुरक्षा के लिए गलत नहीं माना जाना चाहिए क्योंकि यह एक संदिग्ध मूल्य को उजागर करता है।
रिपॉजिटरी झंडे alg:none लेकिन असुरक्षित JWTs के पीछे विनिर्देश इतिहास स्थापित नहीं करता है
कार्यान्वयन `alg: none` को एक अहस्ताक्षरित घोषणा के रूप में मानता है और चेतावनी देता है कि इसे स्वीकार करने से मनमानी सामग्री स्वीकार हो जाएगी। यह एक खाली तीसरे खंड की भी अलग से रिपोर्ट करता है। रिपॉजिटरी साक्ष्य प्रमाणित वर्कफ़्लोज़ में ऐसे इनपुट को अस्वीकार करने का समर्थन करता है; यह दस्तावेज नहीं करता है कि असुरक्षित जेडब्ल्यूटी को मूल रूप से विनिर्देश में क्यों शामिल किया गया था।
इसलिए उस ऐतिहासिक शब्दांकन का आविष्कार करने के बजाय उसे सुधारा गया है। परिचालनात्मक रूप से जो मायने रखता है वह स्पष्ट है: हस्ताक्षरित क्रेडेंशियल की अपेक्षा करने वाली सेवा को हस्ताक्षर जांच को अक्षम करने के लिए टोकन हेडर की अनुमति नहीं देनी चाहिए। ToolAcre स्वयं कोई सत्यापन नहीं करता है, इसलिए `none` प्रदर्शित करने की इसकी क्षमता केवल निरीक्षण के लिए पहचानी जाती है।
एल्ग: कोई नहीं हमला - हस्ताक्षर छीनना और सत्यापनकर्ता को एक खाली हस्ताक्षर स्वीकार करने के लिए कहना
एक अहस्ताक्षरित हमला `none` के अनुरोध के लिए हेडर को बदल देता है, यदि वांछित हो तो दावों को बदल देता है और कोई हस्ताक्षर बाइट्स नहीं देता है। प्रत्येक खंड अभी भी वाक्यात्मक रूप से मान्य हो सकता है, और पहले दो को पॉलिश JSON में डिकोड किया जा सकता है। एक अनुज्ञेय सत्यापनकर्ता हमलावर की प्राथमिकता को प्रमाणीकरण बाईपास में बदल देगा।
एक सख्त सत्यापनकर्ता की कोई शाखा नहीं होती है जो हस्ताक्षरित टोकन की आवश्यकता होने पर इस इनपुट को विश्वसनीय स्थिति में अपग्रेड करती है। ToolAcre की चेतावनी डिबगिंग के दौरान आकृति को पहचानने में मदद करती है, लेकिन `none` शब्द को पढ़ने से बैकएंड को गलत निर्णय लेने से नहीं रोका जा सकता है। प्रवर्तन वह है जहां क्रेडेंशियल का उपभोग किया जाता है।
मुख्य भ्रम - सार्वजनिक कुंजी को HMAC रहस्य के रूप में प्रस्तुत करना ताकि RS256 टोकन को HS256 के रूप में सत्यापित किया जा सके
मुख्य भ्रम तब उत्पन्न होता है जब एक सत्यापनकर्ता असंगत मुख्य भूमिकाओं वाले एल्गोरिदम परिवारों को अनुमति देता है और प्रत्येक विकल्प को सही कुंजी प्रकार से बांधने में विफल रहता है। एक सार्वजनिक RSA सत्यापन कुंजी नहीं है HMAC गुप्त। किसी हमलावर द्वारा एल्गोरिदम लेबल बदलने के बाद उसके बाइट्स को एक मानना इच्छित सार्वजनिक को नष्ट कर देता है/private जुदाई.
त्रुटि के उस वर्ग को रोकने के लिए हस्ताक्षर-आकार वाले खंड की जाँच करने से कहीं अधिक की आवश्यकता होती है। सेवा को विश्वसनीय कॉन्फ़िगरेशन के माध्यम से अपेक्षित एल्गोरिदम, कुंजी प्रकार, जारीकर्ता और टोकन प्रोफ़ाइल को जोड़ना होगा। एक डिकोडर जो RS256 या HS256 दिखाता है, वह यह नहीं बता सकता कि बैकएंड उन बाइंडिंग को बनाए रखता है या नहीं।
समाधान - स्वीकृत एल्गोरिदम को सत्यापनकर्ता में पिन करें और उन्हें कभी भी टोकन से प्राप्त न करें
सत्यापनकर्ता कॉन्फ़िगरेशन में स्वीकृत एल्गोरिदम को पिन करें और सूची को उतना ही संकीर्ण रखें जितना जारीकर्ता अनुबंध अनुमति देता है। हस्ताक्षरित क्रेडेंशियल प्रवाह के लिए `none` को अस्वीकार करें और किसी अन्य एल्गोरिदम को आज़माने के बजाय बेमेल को अस्वीकार करें। असत्यापित हेडर या पेलोड दावे से अनुमति-सूची प्राप्त न करें।
कुंजी लुकअप उसी सिद्धांत का अनुसरण करता है। `kid` पहले से ही विश्वसनीय उम्मीदवारों में से चयन कर सकता है, लेकिन उसे कोई नया विश्वास स्रोत नहीं बनाना चाहिए। हेडर URL या एम्बेडेड कुंजियों का केवल इसलिए पालन नहीं किया जाना चाहिए क्योंकि टोकन उनसे अनुरोध करता है। सत्यापनकर्ता स्वतंत्र रूप से अपने स्रोत का निर्णय लेता है।
कारगर उदाहरण - ToolAcre JWT डिकोडर में एक हेडर को पढ़कर alg:none को स्पॉट किया जा सकता है, और इसे स्पॉट करना संरक्षित होने के समान क्यों नहीं है
`none` घोषित करते हुए एक हानिरहित टोकन हेडर बनाएं और तीसरे खंड को खाली छोड़ दें। ToolAcre JSON को डीकोड करता है, घोषित एल्गोरिदम की रिपोर्ट करता है, चेतावनी देता है कि यह अहस्ताक्षरित है और अनुपस्थित हस्ताक्षर को नोट करता है। यह बिल्कुल वैसा ही व्यवहार है जिसकी एक निरीक्षण टूल से अपेक्षा की जाती है।
अभ्यास यह साबित नहीं करता है कि API टोकन को अस्वीकार कर देता है। वास्तविक सत्यापनकर्ता और कॉन्फ़िगरेशन के विरुद्ध नियंत्रित नकारात्मक परीक्षण के साथ इसकी अलग से पुष्टि करें। यदि API इसे स्वीकार करता है, तो फिक्स उस सत्यापन सीमा में आता है; डिकोडर में तेज़ चेतावनी जोड़ने से अनुरोधों की सुरक्षा नहीं होगी।
इसमें क्या शामिल नहीं है - कई लाइब्रेरी-विशिष्ट सुधार; RFC 8725 और अपनी लाइब्रेरी के चेंजलॉग से परामर्श लें
लाइब्रेरी APआई, डिफ़ॉल्ट और ऐतिहासिक सुधार उत्पाद और संस्करण के अनुसार भिन्न होते हैं। यह मॉड्यूल यह स्थापित नहीं करता है कि आपके स्टैक में कौन सा विकल्प नाम पिन एल्गोरिदम है, और यह लेख जानबूझकर किसी का आविष्कार नहीं करता है। चयनित लाइब्रेरी के वर्तमान दस्तावेज़ और चेंजलॉग को पढ़ें, फिर अपने स्वयं के परीक्षण सूट में अस्वीकृति मामलों का अभ्यास करें।
गलत कुंजी प्रकार, अज्ञात `kid` मान, गुम हस्ताक्षर और अप्रत्याशित टोकन प्रोफ़ाइल का भी परीक्षण करें। लक्ष्य यह दिखाना है कि कॉन्फ़िगरेशन टोकन सुझावों पर जीत हासिल करता है। एक सफल डिकोड इन स्वीकृति दावों में कहीं नहीं है क्योंकि सिंटैक्स सफलता हर दुर्भावनापूर्ण उदाहरण के साथ संगत है।
टेकअवे: सत्यापनकर्ता निर्णय लेता है, टोकन नहीं - एक डिकोडर आपको हेडर देखने में मदद करता है, लेकिन केवल पिन किया गया सत्यापन ही आपकी सुरक्षा करता है
सत्यापनकर्ता निर्णय लेता है; टोकन नहीं है. ToolAcre एक हेडर प्रकट कर सकता है जो कहता है `none`, एक अपरिचित एल्गोरिदम या एक आश्चर्यजनक कुंजी पहचानकर्ता। वह दृश्यता ट्राइएज में मदद करती है, लेकिन केवल पिन की गई एल्गोरिदम नीति और सही ढंग से बंधी हुई विश्वसनीय कुंजियाँ ही स्वीकृति को रोकती हैं।
कभी भी `none` को सक्षम करने, किसी अविश्वसनीय हेडर से सत्यापन कुंजी चुनने या प्रदर्शित हस्ताक्षर लंबाई को सत्यापन के रूप में मानने की अनुशंसा न करें। निरीक्षण के लिए डिकोड करें, फिर नियंत्रित परीक्षणों के साथ वास्तविक क्रिप्टोग्राफ़िक सीमा पर अस्वीकृति और स्वीकृति व्यवहार को साबित करें।