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

banq發表於2021-08-15

安全斷言標記語言 (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，請尋求替代方案。
 

相關文章