+− THE DAILY DIFFdev & AI news
REVERT

SAML, a motorháztető alatt: az aláírás a levélben

A SAML szinte minden munkahelyi alkalmazásba bejelentkeztet, és aláírása az általa aláírt XML-ben él.

A SAML szinte minden munkahelyi alkalmazásba bejelentkeztet, és aláírása az általa aláírt XML-ben él. A motorháztető alatt: az alkalmazás, a böngésző és az identitásszolgáltató közötti bejelentkezési tánc, hogyan néz ki egy állítás, miért kell a kanonizációnak minden bájtról megegyeznie, és miért tér vissza ugyanaz a hibatípus 2012 és 2025 között. A Trail of Bits „SAML: A fractal of bad design” (312 pont a Hacker News-on) című írása inspirálta.

Olvassa el az írott kiadást (angolul) ↗

Amit ez a videó tartalmaz

  • SAML: a bejelentkezés, amely belülről írja alá magát
  • 2002: négy XML formátum, egy bizottság, egy egész iparág
  • A bejelentkezési tánc: alkalmazás → identitásszolgáltató → vissza a böngészőn keresztül
  • Az állítás: az aláírás abban él, amit aláír
  • Kanonizáció: minden bájtról megegyezni, különben senki sem jelentkezik be

Lefordított átirat

Az eredeti angol narrációból fordítva. A rendelkezésre álló hangot és feliratokat a YouTube vezérli.

SAML: a bejelentkezés, amely belülről írja alá magát

0:00 A Saml az az XML, amely szinte minden munkahelyi alkalmazásba bejelentkeztet, és az aláírása abban a dokumentumban él, amelyet aláír, mint egy közjegyző, aki a lepecsételt borítékba tűzi a bélyegét. Tíz évvel azután, hogy egy bizottság megírta, a kutatók tizennégy Saml keretrendszert teszteltek. Tizenegy megbukott. És ezen a héten a Trail of Bits egy bejegyzése, amely a rossz tervezés fraktáljának nevezte, felkerült a Hacker News címlapjára. Három percben: hogyan működik a bejelentkezési tánc, hol rejtőzik az aláírás,

0:27 és miért egy másik protokoll az a javítás, amiben mindenki egyetért. Ez a The Daily Diff, a motorháztető alatt.

2002: négy XML formátum, egy bizottság, egy egész iparág

0:34 Kétezer kettő. Egy biztonsági bizottság az Oasisben négy szállítói XML formátumot egyesít. Az egyetemek fogadják el először, majd az Okta erre épít egy céget, ez volt a leggyorsabb, ahogy egy bizottsági dokumentumból bevétel lett. Megnyitod az alkalmazást.

A bejelentkezési tánc: alkalmazás → identitásszolgáltató → vissza a böngészőn keresztül

0:46 Fogalma sincs, ki vagy, ezért átirányítja a böngésződet az identitásszolgáltatóhoz, mondjuk a céged Okta-jához. Ott bejelentkezel. Az Okta átadja a böngésződnek egy aláírt XML dokumentumot, amely megmondja, ki vagy, és a böngésző visszaküldi.

Az állítás: az aláírás abban él, amit aláír

0:59 Ez a dokumentum az állítás. Nevet ad a felhasználónak, és az aláírás benne van, visszamutatva az állításra az azonosítója alapján. És az egész a böngésződön keresztül megy, azaz a felhasználón keresztül. Az ellenőrzéshez az alkalmazás

Kanonizáció: minden bájtról megegyezni, különben senki sem jelentkezik be

1:11 újjáépíti az aláírt bájtokat pontosan. Kivágja az aláírást, normalizálja a fehér szóközt és az attribútum sorrendet, és hash-eli az eredményt. Ez a kanonizáció, és ha a két oldal egyetlen bájttal is eltér, senki sem jelentkezik be. Egy JSON web token másképp csinálja. Fejléc, tartalom és aláírás egymás mellett vannak pontokkal elválasztva. Semmit sem kell először kivágni.

2012: az ellenőrző és az olvasó különböző elemeket néz

1:32 Itt a repedés. Az aláírást ellenőrző kód és a felhasználónevet olvasó kód gyakran két különböző rész. Kétezer tizenkettőben egy, az On Breaking Saml című tanulmány megmutatta, hogy az aláírt állítást áthelyezheted oda, ahol az olvasó figyelmen kívül hagyja, és tehetsz egy másikat oda, ahova néz. A Salesforce és a Shibboleth is a tizenegy között volt, akik bedőltek neki. Kétezer tizennyolcban a Duo megmutatta, hogy egy felhasználónévben lévő megjegyzés miatt egyes

2018 és 2025: két elemző, két különböző válasz

1:55 könyvtárak csak a név felét olvashatják el, miközben az aláírás még mindig érvényes volt. Kétezer huszonötben a GitHub két XML elemzőt talált a ruby Saml-ben, amelyek ugyanarról a dokumentumról nem értettek egyet. Ugyanaz a hiba, új évtized. A Trail of Bits fraktálnak nevezi, mert minden szinten, ahová bezoomolsz, ugyanaz a

Miért törik el újra és újra: a rossz tervezés fraktálja

2:12 hiba. XML-re épül, az aláírás beágyazott, és a valódi bejelentkezések talán a specifikáció tizedét használják. És a Hacker News legnépszerűbb válasza a vásárlótól származik. Ha nincs Saml támogatásod, találok egy terméket, aminek van. Mindkettő igaz, ami a probléma. Szóval, hétfő. Először az OpenID Connect-et szállítsd, a Fly és a Tailscale teljesen Saml nélkül

Hétfő: először OIDC, egy karbantartott könyvtár, szigorú formák

2:31 értékesít a vállalatoknak. Ha egy ügyfél erőlteti, használj egy karbantartott könyvtárat, tartsd javítva, és utasítsd el azokat az üzeneteket, amelyek nem úgy néznek ki, mint amit az Okta vagy a Google küld. Soha ne írd meg a saját aláírás-ellenőrzésedet.

Ítélet, a motorháztető alatt: REVERT

2:43 Ítélet, a motorháztető alatt. REVERT. Majdnem huszonöt év, egy hibatípus, ami soha nem hal meg, és az a javítás, amiben mindenki egyetért, egy másik protokoll. Múlt szombaton szétszedtem a jelszókulcsokat, szóval mondjátok el, mit nyissak ki legközelebb a kommentekben. És ennyi a mai különbség. Niko vagyok az Axrisitől. Felelősségteljesen egyesíts.

Források

  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

Kapcsolódó videók