डेवलपर टूल · JWT डिकोडर
दर्शकों और जारीकर्ता की जांच: JWT को अन्यत्र दोबारा चलाने से रोकना
· यह क्यों मायने रखती है
जेडब्ल्यूटी प्रमाणीकरण सुरक्षा
एक सेवा के लिए जारी किया गया टोकन उसी जारीकर्ता को साझा करने वाली किसी अन्य सेवा को प्रस्तुत किया जा सकता है। यह पोस्ट बताती है कि ऑड और आईएस चेक इसे कैसे रोकते हैं, और एक टोकन में दोनों दावों को कैसे पढ़ा जाए।
सेवा बी सेवा ए के लिए एक टोकन स्वीकार करती है - क्रॉस-सर्विस रीप्ले जिसे वैध हस्ताक्षर रोकता नहीं है
एक हस्ताक्षर उस टोकन के लिए मान्य हो सकता है जो किसी भिन्न सेवा के लिए जारी किया गया था। यदि कई APआई एक ही पहचान प्लेटफ़ॉर्म पर भरोसा करते हैं लेकिन प्राप्तकर्ता संदर्भ को अनदेखा करते हैं, तो सेवा ए के लिए इच्छित क्रेडेंशियल को सेवा बी में दोबारा चलाया जा सकता है। अकेले क्रिप्टोग्राफ़िक अखंडता यह उत्तर नहीं देती है कि इसका उपभोग किसे करना चाहिए।
ToolAcre `iss` और `aud` को प्रकट कर सकता है ताकि डेवलपर एक स्पष्ट बेमेल का पता लगा सके। हस्ताक्षर सफल होने तक वे स्ट्रिंग्स असत्यापित रहती हैं, और ब्राउज़र टूल कभी भी वह जाँच नहीं करता है। वास्तविक संसाधन सर्वर को अपने जारीकर्ता संबंध और इच्छित दर्शकों दोनों को लागू करना होगा।
आईएसएस - आपकी सेवा जिस जारीकर्ता पर भरोसा करती है, उसके साथ एक टोकन बाइंडिंग, और कुंजी बाइंडिंग के बिना एक स्ट्रिंग मैच पर्याप्त क्यों नहीं है
`iss` उस इकाई की पहचान करता है जिसका पेलोड दावा टोकन जारी करता है। एक सत्यापनकर्ता को अपने स्वयं के कॉन्फ़िगरेशन के तहत एक सटीक अपेक्षित जारीकर्ता की आवश्यकता होती है और उसे उस पहचान को सही कुंजी-खोज संबंध से जोड़ना होगा। क्रिप्टोग्राफ़िक बाइंडिंग के बिना पाठ की तुलना करने से हमलावर के लिए अपेक्षित स्ट्रिंग की प्रतिलिपि बनाने की गुंजाइश निकल जाती है।
डिकोडर `iss` को "टोकन किसने बनाया" के रूप में वर्णित करता है, लेकिन यह पंजीकृत अर्थ है, चिपकाए गए मूल्य के बारे में कोई खोज नहीं। पढ़ने योग्य जारीकर्ता पाठ डिबगिंग कॉन्फ़िगरेशन के लिए उपयोगी साक्ष्य है। यह किसी मनमाने कुंजी स्रोत का चयन नहीं कर सकता या स्वयं को प्रमाणित नहीं कर सकता।
aud - इच्छित प्राप्तकर्ताओं को नामित करने वाली एक स्ट्रिंग या एक सरणी, और नियम है कि एक सत्यापनकर्ता को इसमें स्वयं को ढूंढना होगा
`aud` इच्छित प्राप्तकर्ताओं के नाम और एक स्ट्रिंग या संग्रह के रूप में प्रकट हो सकते हैं। संसाधन सर्वर की नीति को उसके प्रोफ़ाइल के लिए आवश्यक सटीक तुलना नियमों का उपयोग करके स्वयं को प्रमाणित मूल्य में खोजना होगा। इसे केवल इसलिए टोकन स्वीकार नहीं करना चाहिए क्योंकि कोई अन्य परिचित सेवा सूचीबद्ध है।
ToolAcre अपनी दावा तालिका में सारणियों को JSON पाठ के रूप में रखता है, निरीक्षण के लिए उनकी दृश्य संरचना को संरक्षित करता है। यह वर्तमान API के पहचानकर्ता को नहीं जानता है और किसी मैच का निर्णय नहीं कर सकता है। वह जानबूझकर अनुपस्थिति एक सामान्य डिकोडर को उस प्राधिकरण संदर्भ का आविष्कार करने से रोकती है जो उसके पास नहीं है।
एज़पी और स्कोप - ओपनID कनेक्ट और ओएथ का दावा है कि यह परिष्कृत करें कि टोकन का उपयोग कौन और किसके लिए कर सकता है
`azp` और `scope` प्रोफाइल में किसी अधिकृत पार्टी और अनुरोधित अनुमतियों के बारे में संदर्भ जोड़ सकते हैं जो उन्हें परिभाषित करते हैं। वे दर्शकों, जारीकर्ता या हस्ताक्षर चेक को प्रतिस्थापित नहीं करते हैं। एक स्कोप नाम एक दावा है, अनुमति अनुदान नहीं है जब तक कि संसाधन सर्वर अपनी नीति के लिए एक प्रमाणित मान को मैप नहीं करता है।
वर्तमान डिकोडर इन्हें एप्लिकेशन-विशिष्ट दावों के रूप में मानता है क्योंकि इसकी पंजीकृत-विवरण तालिका में सात मुख्य नाम शामिल हैं। यह उनके मान प्रदर्शित करता है लेकिन कोई OpenID कनेक्ट या OAuth शब्दार्थ प्रदान नहीं करता है। किसी निर्णय में उपयोग करने से पहले लागू प्रोफ़ाइल और प्रदाता अनुबंध से परामर्श लें।
भ्रमित-डिप्टी पैटर्न - जब दर्शकों की जाँच नहीं की जाती है तो एक वैध टोकन कैसे हमला बन जाता है
एक भ्रमित डिप्टी अनपेक्षित संदर्भ में वैध अधिकार का उपयोग करता है। गलत सेवा द्वारा स्वीकार किया गया टोकन ठीक उसी पैटर्न को ट्रिगर कर सकता है, भले ही किसी ने हस्ताक्षर न किया हो। श्रोता उस सीमा की जांच करते हैं जहां प्रमाणित दावे लागू किए जा सकते हैं, जबकि जारीकर्ता उस सीमा की जांच करता है जिसके दावे पर सेवा विचार करती है।
यही कारण है कि एक सामान्य "हस्ताक्षर वैध" ध्वज अभी भी अपर्याप्त होगा। प्राधिकरण प्राप्तकर्ता और संचालन पर निर्भर करता है। ToolAcre बिना किसी सत्यापन परिणाम की रिपोर्ट करके उस अस्पष्टता से पूरी तरह से बचता है, उपभोक्ता सेवा को प्रासंगिक नीति के साथ क्रिप्टोग्राफी को संयोजित करने के लिए छोड़ देता है।
व्यावहारिक उदाहरण - ToolAcre JWT डिकोडर में दो टोकन से iss और aud को पढ़ना और यह तय करना कि कौन सी सेवा प्रत्येक को स्वीकार करेगी
दो हानिरहित टोकन बनाएं जिनके डिकोडेड पेलोड केवल `aud` में भिन्न हों: एक का नाम `service-a` है, दूसरे का नाम `service-b` है; दोनों एक ही जारीकर्ता का दावा करते हैं। ToolAcre अंतर को दृश्यमान बनाता है। एक सेवा-ए सत्यापनकर्ता को न केवल इस प्रदर्शन से स्वीकार करना चाहिए और प्रमाणित सेवा-बी दर्शकों को अस्वीकार करना चाहिए।
फिर दो जारीकर्ता स्ट्रिंग के साथ अभ्यास को उलट दें। अकेले अपेक्षित पाठ पर्याप्त नहीं है जब तक कि सत्यापन में उस जारीकर्ता के लिए विश्वसनीय कुंजियों का उपयोग न किया जाए। ये उदाहरण निरीक्षण को स्वीकृति से अलग करते हैं और दिखाते हैं कि सही दिखने वाले दावों को मनगढ़ंत टोकन में कॉपी करने से कोई विश्वसनीय नीति क्यों नहीं बदलती है।
इसमें क्या शामिल नहीं है - हस्ताक्षर सत्यापन, जो डिकोडर कभी नहीं करता है; ऑड और आईएस चेक केवल हस्ताक्षर के बाद ही मायने रखते हैं
दर्शकों और जारीकर्ता की जाँच केवल तभी मायने रखती है जब क्रिप्टोग्राफ़िक सत्यापन यह स्थापित करता है कि संरक्षित बाइट्स विश्वसनीय कुंजी सामग्री के अनुरूप हैं। ToolAcre इनमें से कोई भी सत्यापन नहीं करता है। इसका आउटपुट यह स्थापित नहीं कर सकता कि कोई दावा बरकरार है या किसी ज्ञात जारीकर्ता ने इसे लिखा है।
यह मेटाडेटा भी नहीं लाता, कुंजियाँ नहीं चुनता या कॉन्फ़िगर किए गए प्राप्तकर्ताओं की तुलना नहीं करता। गलत जारीकर्ता और गलत दर्शकों के लिए अस्वीकृति साबित करने के लिए बैकएंड परीक्षण और लॉग का उपयोग करें। डिकोडर में एक दृश्य मिलान एक डिबगिंग सुराग है, कभी भी पर्याप्त प्राधिकरण प्रमाण नहीं है।
टेकअवे: जांचें कि यह किसके लिए है, न कि केवल जिसने इस पर हस्ताक्षर किए हैं - ToolAcre JWT डिकोडर ऑड और आईएस दावों को दिखाता है जिनकी आपको तुलना करने की आवश्यकता है
यह जांचें कि टोकन किसके लिए है, न कि केवल उस नाम का जिस पर हस्ताक्षर किया गया है। मजबूत प्रवाह एक स्वतंत्र रूप से विश्वसनीय जारीकर्ता संबंध के तहत संरक्षित बाइट्स को प्रमाणित करता है, फिर एक स्वीकार्य दर्शकों की आवश्यकता होती है और सेवा-विशिष्ट प्राधिकरण नियमों को लागू करता है।
सुरक्षित परीक्षण मान पढ़ने और अगली सर्वर-साइड जांच तैयार करने के लिए ToolAcre का उपयोग करें। अविश्वसनीय हेडर या दावा डेटा से सत्यापन कुंजी न चुनें, और पूर्ण विश्वसनीय प्रवाह के बिना प्रदर्शित `iss`, `aud`, `azp` या `scope` को अनुदान में न बदलें।