SAML, तह के नीचे: पत्र के अंदर का हस्ताक्षर

इस वीडियो में क्या शामिल है

• SAML: वह लॉगिन जो अंदर से ही खुद पर हस्ताक्षर करता है
• 2002: चार XML प्रारूप, एक समिति, एक पूरा उद्योग
• लॉगिन प्रक्रिया: ऐप → पहचान प्रदाता → आपके ब्राउज़र के माध्यम से वापस
• अभिकथन: हस्ताक्षर उसके अंदर रहता है जिस पर यह हस्ताक्षर करता है
• विहितीकरण: हर बाइट पर सहमत हों, या कोई लॉग इन नहीं करेगा

अनुवादित प्रतिलेख

मूल अंग्रेजी कथन से अनुवादित। उपलब्ध ऑडियो और कैप्शन YouTube द्वारा नियंत्रित होते हैं।

SAML: वह लॉगिन जो अंदर से ही खुद पर हस्ताक्षर करता है

0:00 SAML वह XML है जो आपको आपके लगभग हर काम के ऐप में लॉग इन करता है, और इसका हस्ताक्षर उस दस्तावेज़ के अंदर रहता है जिस पर यह हस्ताक्षर करता है, जैसे एक नोटरी अपने मोहर को उस लिफाफे के अंदर लगाता है जिसे वह सील कर रहा है। एक समिति द्वारा इसे लिखने के दस साल बाद, शोधकर्ताओं ने चौदह SAML ढांचों का परीक्षण किया। ग्यारह विफल रहे। और इस सप्ताह Trail of Bits की एक पोस्ट में इसे खराब डिज़ाइन का एक फ्रैक्चरल कहा गया, जो Hacker News के मुख्य पृष्ठ पर आया। तीन मिनट में: लॉगिन प्रक्रिया कैसे काम करती है, हस्ताक्षर कहाँ छिपा है,

0:27 और जिस समाधान पर सभी सहमत हैं वह एक अलग प्रोटोकॉल क्यों है। यह The Daily Diff है, तह के नीचे।

2002: चार XML प्रारूप, एक समिति, एक पूरा उद्योग

0:34 दो हज़ार दो। ओएसिस में एक सुरक्षा समिति चार विक्रेता XML प्रारूपों को एक में मिलाती है। विश्वविद्यालय पहले इसे अपनाते हैं, फिर ओक्टा इस पर एक कंपनी बनाता है, सबसे तेज़ी से एक समिति दस्तावेज़ कभी राजस्व में बदला। आप ऐप खोलते हैं।

लॉगिन प्रक्रिया: ऐप → पहचान प्रदाता → आपके ब्राउज़र के माध्यम से वापस

0:46 इसे कोई जानकारी नहीं है कि आप कौन हैं, इसलिए यह आपके ब्राउज़र को पहचान प्रदाता पर उछाल देता है, जैसे आपकी कंपनी का Okta। आप वहाँ लॉग इन करते हैं। Okta आपके ब्राउज़र को एक हस्ताक्षरित XML दस्तावेज़ देता है जो बताता है कि आप कौन हैं, और ब्राउज़र इसे वापस पोस्ट करता है।

अभिकथन: हस्ताक्षर उसके अंदर रहता है जिस पर यह हस्ताक्षर करता है

0:59 वह दस्तावेज़ अभिकथन है। यह उपयोगकर्ता का नाम बताता है, और हस्ताक्षर इसके अंदर होता है, अपनी ID द्वारा अभिकथन की ओर इशारा करते हुए। और पूरी चीज़ आपके ब्राउज़र के माध्यम से चलती है, जिसका अर्थ है, उपयोगकर्ता के माध्यम से। इसकी जांच करने के लिए, ऐप

विहितीकरण: हर बाइट पर सहमत हों, या कोई लॉग इन नहीं करेगा

1:11 हस्ताक्षरित किए गए सटीक बाइट्स को फिर से बनाता है। यह हस्ताक्षर को वापस काटता है, व्हाइटस्पेस और विशेषता के क्रम को सामान्य करता है, और परिणाम को हैश करता है। यही विहितीकरण है, और यदि दोनों पक्ष एक भी बाइट से असहमत होते हैं, तो कोई भी लॉग इन नहीं कर पाता। एक JSON वेब टोकन इसे अलग तरीके से करता है। हेडर, पेलोड और हस्ताक्षर बीच में डॉट्स के साथ साथ-साथ बैठते हैं। पहले कुछ भी काटने की जरूरत नहीं।

2012: चेकर और रीडर अलग-अलग तत्वों को देखते हैं

1:32 यह दरार है। हस्ताक्षर की जांच करने वाला कोड और उपयोगकर्ता नाम पढ़ने वाला कोड अक्सर दो अलग-अलग टुकड़े होते हैं। 2012 में, On Breaking Saml नामक एक पेपर ने दिखाया कि आप हस्ताक्षरित अभिकथन को वहाँ ले जा सकते हैं जहाँ रीडर इसे अनदेखा करता है, और दूसरा वहाँ रख सकते हैं जहाँ वह देखता है। Salesforce और Shibboleth उन ग्यारह में से थे जो इसके झांसे में आ गए। 2018 में, Duo ने दिखाया कि उपयोगकर्ता नाम के अंदर एक टिप्पणी कुछ लाइब्रेरियों को नाम का केवल आधा हिस्सा पढ़ने के लिए मजबूर कर सकती है, जबकि हस्ताक्षर अभी भी सही होता है।

2018 और 2025: दो पार्सर, दो अलग-अलग उत्तर

1:55 2025 में, GitHub को ruby Saml के अंदर दो XML पार्सर एक ही दस्तावेज़ के बारे में असहमति रखते हुए मिले। वही बग, नया दशक। ट्रेल ऑफ बिट्स इसे एक फ्रैक्चरल कहता है, क्योंकि हर स्तर पर जिसे आप ज़ूम करते हैं उसमें वही दोष होता है। यह XML पर बना है, हस्ताक्षर संलग्न है,

यह बार-बार क्यों टूटता है: बुरे डिजाइन का एक भग्न

2:12 और वास्तविक लॉगिन विनिर्देश के शायद दसवें हिस्से का उपयोग करते हैं। और हैकर न्यूज़ पर शीर्ष उत्तर खरीदार से आता है। यदि आपके पास SAML समर्थन नहीं है, तो मैं एक ऐसा उत्पाद ढूंढ सकता हूँ जिसमें है। दोनों सच हैं, जो समस्या है। तो, सोमवार। पहले OpenID Connect शिप करें, Fly और Tailscale उद्यमों को बिना SAML के बेचते हैं।

सोमवार: पहले OIDC, एक रखरखाव वाली लाइब्रेरी, सख्त आकार

2:31 यदि कोई ग्राहक इसे मजबूर करता है, तो एक रखरखाव वाली लाइब्रेरी का उपयोग करें, इसे पैच रखें, और ऐसे संदेशों को अस्वीकार करें जो Okta या Google द्वारा भेजे गए संदेशों जैसे न दिखें। कभी भी अपनी खुद की हस्ताक्षर जांच न लिखें। निर्णय, तह के नीचे।

निर्णय, तह के नीचे: REVERT

2:43 REVERT। लगभग पच्चीस साल, एक बग क्लास जो कभी नहीं मरती, और जिस समाधान पर सभी सहमत हैं वह एक अलग प्रोटोकॉल है। पिछले शनिवार मैंने पासकीज़ को अलग किया था, तो मुझे बताएं कि टिप्पणियों में आगे क्या खोलना है। और आज के लिए इतना ही अंतर है। मैं Axrisi से Niko हूँ। जिम्मेदारी से विलय करें। जिम्मेदारी से विलय करें।

स्रोत

1. Trail of Bits, "SAML: A fractal of bad design" (Matt Schwager, Sep 21, 2026)blog.trailofbits.com
2. Hacker News threadnews.ycombinator.com
3. Somorovsky et al., "On Breaking SAML: Be Whoever You Want to Be", USENIX Security 2012www.usenix.org
4. Duo Labs, SAML vulnerabilities affecting multiple implementations (2018): https://duo.com/blog/duo-finds-saml-vulnerabilities-affecting-multiple-implementations · CERT VU#475445www.kb.cert.org
5. GitHub Security Lab, "Sign in as anyone: Bypassing SAML SSO authentication with parser differentials" (Mar 12, 2025)github.blog