SAML 在設計上是不安全的 | joonas.fi

解道jdon 2021-08-15 12:16:20 阅读数:123

本文一共[544]字,预计阅读时长:1分钟~
saml 不安全 不安 安全 joonas.fi

安全斷言標記語言 (SAML) 是一種用於在各方之間交換身份驗證和授權數據的開放標准。SAML 通常用於單點登錄 (“使用 Google 登錄”、“使用 Twitter 登錄”等)。這意味著當您想登錄 example.com 時,example.com 可以信任並使用外部身份驗證提供程序來為您斷言用戶的身份。SAML 是關於跨組織邊界(網絡域)傳達這些身份驗證和身份詳細信息。

雖然 Google支持 SAML用例,但 Google/Facebook 主要使用 OAuth2 來處理這些“使用 Google 登錄”一般公共身份驗證流程。

 

SAML 用於很多地方,它也可能影響您的安全。

SAML 最近出現了灾難性的漏洞 ,影響非常大。例如,如果我理解正確(我可能理解,因為安全研究人員轉發了我的反應)芬蘭稅務機關,大多數政府服務和健康記錄系統都很脆弱,攻擊者可能會繼續窺探人們的納稅申報錶、健康記錄以及基本上任何可在線獲取的與政府相關的內容。

它在很大程度上被媒體忽略了,也許是因為這些漏洞沒有被利用(或者沒有檢測到這樣的實例)。

 

為什麼 SAML 不安全?

SAML 使用基於計算值的簽名。這種做法本質上是不安全的,因此 SAML 作為設計是不安全的。

 

為什麼對計算值進行簽名很危險?

總而言之:一旦您將安全性基於某些計算屬性,您現在就可以利用此計算中的任何缺陷、差异或歧義。計算越複雜,就越危險。SAML 簽名計算非常複雜。

但是讓我們繼續解釋這個概念。讓我們拿一個偽身份文件(盡管實際 SAML 是 XML):

$ cat assertion.json
{
  "signed_in_user": "Joonas"
}

我們可以簽署上面的文件,就像一堆字節:

$ cat assertion.json | sha1sum
e58dc03a7491f9e5fb2ed664b23d826489c42cc5

現在,如果我們稍微更改文件(我在 {之前添加了空格)。我們注意到簽名發生了變化:

$ cat assertion.json
 {
  "signed_in_user": "Joonas"
}
$ cat assertion.json | sha1sum
0bc80a9ee02f611b70319c9fe12b7e504107354a

這是一個非常好的屬性,因為理想情况下,我們希望對安全關鍵文檔(SAML 是)的任何更改(即使是那些在 JSON 級別被認為毫無意義的更改)以生成不同的簽名。

此屬性稱為不可延展性

 延展性通用定義

可以在不破碎的情况下塑造成其他東西的東西的質量,例如粘土的延展性。

我們將blob文檔簽名為原始字節 使得這種不可延展性,即它不能在不破壞它的情况下成形。這是信息安全領域的理想行為。

SAML 具有延展性,因為它的簽名基於計算值,

 

為了通過示例進行解釋,讓我們回到 JSON 示例。我們將使用jq (一個 JSON 轉換實用程序)從我們的文檔內部計算一些東西:

$ cat assertion.json
 {
  "signed_in_user": "Joonas"
}
$ cat assertion.json | jq .
{
  "signed_in_user": "Joonas"
}

(jq .意味著只需重新打印整個文檔)

注意文件是如何通過管道jq删除空間的?那是因為在 JSON 級別,空間並不重要。乍一看,這似乎並不有趣,但我們正在快速前往 危險區域

讓我們對計算值進行簽名:

$ cat assertion.json | jq . | sha1sum
e58dc03a7491f9e5fb2ed664b23d826489c42cc5

即使文件仍然有空格修改,簽名現在與原始簽名匹配(來自沒有添加空格的文件)。

為什麼這很危險?讓我們再次更改文件:

$ cat assertion.json
{
  "signed_in_user": "EvilAttacker",
  "signed_in_user": "Joonas"
}
$ cat assertion.json | jq . | sha1sum
e58dc03a7491f9e5fb2ed664b23d826489c42cc5
# the above is because:
$ cat assertion.json | jq .
{
  "signed_in_user": "Joonas"
}

簽名仍然與原始文件匹配。這是因為重複鍵是有效的 JSON,在處理時被删除,並且大多數 JSON 實現讓最後一個鍵獲勝。

現在,如果您有兩段不同的代碼來處理 SAML 文檔,並且它們對 JSON 重複鍵(= 消息語義內容)有不同的解釋/解析器行為,會發生什麼?

攻擊者要求身份提供者為他簽署斷言,但由於 SAML 的延展性,他能够攻擊解析器差异並篡改文檔,使其對簽名驗證仍然有效,但可以訪問不同用戶的數據。

現在我希望解釋了延展性和基於計算/解釋內容的簽名是多麼危險。

 

實踐中的 SAML 漏洞

這些 SAML 漏洞發生的事情並不像我們的 JSON 示例那麼簡單,但這說明了這些漏洞的原理及其根本原因:對計算值和延展性進行簽名。

最新的漏洞是由於 XML 往返不穩定性造成的 (請參閱標題“XML 往返漏洞是什麼樣的”)。

總之,當解析 XML -> 編寫 XML 產生語義不同的文檔時,就會出現漏洞,即encode(decode(xmlDocument)) != xmlDocument)。

 

....

點擊標題

讓我們擺脫 SAML。 一些專家似乎推薦 OAuth2 或 OpenID Connect:

如果供應商向您提供 SAML,請尋求替代方案。

 

版权声明:本文为[解道jdon]所创,转载请带上原文链接,感谢。 https://gsmany.com/2021/08/20210815121613077c.html