+− THE DAILY DIFFdev & AI news
REVERT

SAML,內部構造:信件中的簽名

SAML 讓您登入幾乎所有工作應用程式,其簽名位於所簽署的 XML 內部。

SAML 讓您登入幾乎所有工作應用程式,其簽名位於所簽署的 XML 內部。內部構造:應用程式、瀏覽器和身分提供者之間的登入過程,斷言的樣子,為何正規化必須就每個位元組達成一致,以及為何相同的錯誤類別從 2012 年到 2025 年一直重現。受 Trail of Bits 的「SAML:壞設計的碎形」(在 Hacker News 上獲得 312 分) 啟發。

閱讀書面版本(英文) ↗

本影片涵蓋的內容

  • SAML:從內部自行簽署的登入
  • 2002年:四種XML格式,一個委員會,一個完整產業
  • 登入流程:應用程式 → 身分提供者 → 透過瀏覽器返回
  • 斷言:簽名位於它所簽署的內容內部
  • 正規化:就每個位元組達成一致,否則無人能登入

翻譯的文字記錄

從英文原文旁白翻譯。可用的音頻和字幕由 YouTube 控制。

SAML:從內部自行簽署的登入

0:00 SAML 是讓您登入幾乎所有工作應用程式的 XML 文件, 它的簽名就存在於它所簽署的文件內部, 就像公證人在他密封的信封裡面釘上他的印章一樣。 委員會撰寫完成十年後,研究人員測試了十四個 SAML 框架。其中十一個失效。 而本週 Trail of Bits 的一篇帖子稱其為壞設計的碎形,該帖子登上了 Hacker News 的頭版。 三分鐘內:登入流程如何運作,簽名藏在哪裡,

0:27 以及為何大家一致同意的解決方案是使用不同的協定。 這裡是《The Daily Diff》的內部解析。

2002年:四種XML格式,一個委員會,一個完整產業

0:34 二千零二年。 OASIS 的一個安全委員會將四種供應商的 XML 格式合併為一種。 大學率先採用,然後 Okta 在此基礎上建立公司, 這是一個委員會文件轉化為收入的最快速度。 您打開應用程式。

登入流程:應用程式 → 身分提供者 → 透過瀏覽器返回

0:46 它不知道您是誰,所以它將您的瀏覽器彈到身份提供者, 例如您公司的 Okta。 您在那裡登入。 Okta 將一份已簽署的 XML 文件交給您的瀏覽器,說明您是誰, 然後瀏覽器將其回傳。

斷言:簽名位於它所簽署的內容內部

0:59 這份文件就是斷言 (assertion)。 它指明了用戶,而簽名就在其內部, 透過其 ID 指回斷言。 整個過程都透過您的瀏覽器進行,也就是說, 透過用戶。 為了檢查它,應用程式

正規化:就每個位元組達成一致,否則無人能登入

1:11 重新建構簽名時的確切位元組。 它將簽名切除,標準化空白和屬性 順序,然後哈希處理結果。 這就是正規化 (canonicalization),如果雙方差一個位元組都無法達成一致, 就沒有人能登入。 JSON Web Token 的做法不同。 標頭、負載和簽名並排,中間以點分隔。 無需先切除任何東西。

2012年:檢查器和讀取器查看不同的元素

1:32 問題就在這裡。 檢查簽名的程式碼和讀取用戶名的程式碼 通常是兩個不同的部分。 在 2012 年,一篇名為《On Breaking Saml》的論文展示了你可以將 已簽署的斷言移到讀取器忽略的位置,並在讀取器查看的位置放置第二個斷言 Salesforce 和 Shibboleth 是其中十一個受影響的公司。 2018 年,Duo 展示了一個使用者名稱中的註釋可以使某些

2018年和2025年:兩個解析器,兩個不同的答案

1:55 程式庫只讀取一半名稱,而簽名仍然通過檢查。 2025 年,GitHub 發現在 Ruby SAML 中兩個 XML 解析器 對同一份文件存在分歧。 同樣的錯誤,新的十年。 Trail of Bits 稱之為碎形,因為你深入的每一個層次都存在

為何它不斷出錯:壞設計的碎形

2:12 同樣的缺陷。它建立在 XML 上,簽名是內嵌的, 而實際的登入可能只使用了規範的十分之一。 Hacker News 上的熱門回覆來自買家。 如果您不支援 SAML,我可以找到支援的產品。 兩者都屬實,這就是問題所在。 所以,週一。首先發布 OpenID Connect,Fly 和 Tailscale 將產品賣給

星期一:OIDC優先,一個維護良好的程式庫,嚴格的格式

2:31 完全沒有 SAML 的企業。 如果客戶強制要求,請使用維護良好的程式庫,保持更新, 並拒絕那些看起來不像 Okta 或 Google 發送的訊息。 切勿自行編寫簽名檢查。

內部構造裁決:REVERT

2:43 內部構造裁決。 REVERT。將近二十五年,一個從未消失的錯誤類別, 而大家一致同意的解決方案是使用不同的協定。 上週六我拆解了通行密匙 (passkeys),所以請在評論中告訴我接下來要拆解什麼。 這就是今天的不同之處。 我是 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

相關影片

under-the-hood · zh-HK · 2026年9月19日

通行密匙,原理揭秘

通行密匙是您的設備生成、從不向您顯示,也拒絕交給任何人(包括您自己)的密碼。原理揭秘:WebAuthn 流程(每個網站一對密鑰、質詢、簽名)、瀏覽器寫入以杜絕網絡釣魚的一個字段(來源)、設備綁定與同步密鑰、AAGUID,以及為何「無法釣魚」和「不可移動」是同一個特性——這正是「我不喜歡通行密匙」(在 Hacker News 上獲得 616 點贊)真正要表達的。結論:NEEDS REVIEW — 流

3:12 ↗
under-the-hood · zh-HK · 2026年9月23日

模型「壽終正寢」後,幕後有甚麼變化?

AI 模型不會消亡 — 它只會有一個關閉日期,然後第二天早上,你的 API 呼叫會收到一個 404 錯誤:「此模型已被棄用,請在此處了解更多資訊。」幕後:四階段流程(活躍 → 傳統 → 棄用 → 退役)、通知期限(OpenAI ≥ 6 個月 / 3 個月 / 預覽版約 2 星期;Anthropic ≥ 60 天)、開發人員會遇到甚麼問題(響亮的 404 錯誤、悄無聲息的評估漂移、Claude 4.

3:15 ↗
under-the-hood · zh-HK · 2026年9月18日

遞歸式自我改進:底層解密

Google DeepMind 發佈了《Dream-RSI:透過演化世界實現遞歸式自我改進》——而其中的編碼模型從未改變。底層解密:這個詞語在過去 60 年的含義是什麼,Dream-RSI 中實際循環的是什麼(一個在記錄搜尋樹上「夢想」的 Python 探索策略),以及為什麼 317 次代理呼叫而非 550 次是折扣,而非突破性進展。結論:NEEDS REVIEW。

4:03 ↗