SAML：悪しき設計のフラクタル

学術界で生まれ、企業IT部門で育てられた認証プロトコルであるSAML（Security Assertion Markup Language）は、これらの組織で依然として定番となっています。しかし、その引退の時期が来ています。 2000年代後半のソフトウェア・アズ・ア・サービス（SaaS）企業の台頭に伴い、IT部門は多くの新しいWebサービスへのユーザー認証方法を必要としていました。SAMLと、勃興しつつあったシングルサインオン（SSO）業界がこのニーズを満たしました。しかし、SAMLはその複雑さの重みに押しつぶされつつあります。それを非推奨とし、OpenID Connect（OIDC）のようなモダンな代替手段に移行する時期です。本稿では、SAMLの委員会による設計の起源、学術的および企業環境での昇進、セキュリティ研究コミュニティによるゆっくりとした崩壊、そして（希望的観測として）新しいプロトコルへの移行について探ります。 SAML 101 SAMLの厄介な点は、理解するのはほとんど単純であるにもかかわらず、砂、骨粉、灰の基盤の上に構築されていることです。XML署名検証が信頼できると仮定すれば、それは機能します。しかし、XML署名検証は深く呪われており、あまりにも複雑なため、フィールドのSAML実装のほとんどは、誰も読まない厄介なCコードベースであるlibxmlsecをラップしています。— Thomas Ptacek、2023年 SAMLとSSO業界の誕生 Wikipediaによると、「SAMLはセキュリティアサーションのためのXMLベースのマークアップ言語です。」それは2002年に構造化情報標準化機構（OASIS）のセキュリティサービス技術委員会（SSTC）によって作成されました。現代の基準からすると、良いスタートとは言えません。XMLは、いくつかの評価できる側面があるにもかかわらず、JSONのような新しい代替手段と比較して非常に複雑ですが、それについては後で詳しく説明します。さらに、サブ委員会の委員会が会議を行うことは、「寄せ集め」プロトコル設計（例：ウォーターフォール方法論、ビッグデザインアップフロントなど）のレシピです。そして案の定、私たちは今、4つ (!)のXMLベースのセキュリティプロトコルを1つに詰め込んでいます。 …以下の知的財産がSSTCに寄付されました。 NetegrityからのSecurity Services Markup Language（S2ML） SecurantからのAuthXML VeriSignからのXML Trust Assertion Service Specification（X-TASS） JamcrackerからのInformation Technology Markup Language（ITML） — SAML: History しかし、そのようなプロトコルの必要性は否定できませんでした。インターネットが90年代のWeb 1.0から2000年代初頭のWeb 2.0へと移行するにつれて、ユーザーと組織は多くの新しいWebサービスへの認証を容易に行う方法を必要としていました。学術界はこの動きの最大の推進者でしたが、唯一の推進者ではありませんでした。2002年のイェール大学でのCentral Authentication Service（CAS）、私の母校を含む研究大学のコンソーシアムであるInternet2による2003年のShibboleth IdP、マイクロソフトによる2003年のADFS、そして学術界と密接な関係を持つノルウェーの国営企業Uninettによる2007年頃のsimpleSAMLphp。これらの認証プロジェクトはすべて、最終的に何らかの形でSAMLをサポートしました。ARPANET以前のように、大学はインターネット開発の最前線にあり、Webサービスの最も初期の消費者でした。プロトコルの利用可能性と初期の学術的な検証基盤というこの基盤が確立されると、商業産業はそれを手に取り、数十億ドル規模の産業へと発展させました。 SSO、ID、認証プロバイダー業界も2000年代初頭に始まりましたが、数年後に本格化しました。Ping Identity（2002年）、OneLogin（2009年）、Okta（2009年）、Duo Security（2010年）。これらの企業は、Duoが2015年に最初のSSO製品を導入した（私が物語に関わるようになった時期）ことを除けば、基本的にSAMLプロトコル上に構築されていました。私はDuoの最初のオンプレミスAccess Gateway製品（DAG）に取り組みましたが、これはsimpleSAMLphpと、明らかにSAMLプロトコル上に構築されていました。そこで私はSAMLプロトコルに精通し、その長い仕様を消化するために人生の多くの時間を費やしました。Kelby LudwigがXMLコメントバイパスを発見したとき、私はそこにいましたが、後でさまざまな攻撃とSAMLの欠陥について詳しく説明します。SSOおよび認証プロバイダー業界は隆盛を極め、その多くがSAMLプロトコル上に構築されていたと言えば十分でしょう。 装甲の亀裂 XML署名ラッパー（XSW）攻撃は、SAMLの踵に突き刺さる比喩的な矢です。署名ラッパー（2005年、2008年、2009年）とSAML（2008年）の両方に関する初期のセキュリティ研究がありましたが、私はそれらすべてを「On Breaking SAML: Be Whoever You Want to Be」（2012年）の父と見なしています。それは理論を実践に対してテストし、XSW攻撃をチェックするための自動化された方法をもたらしました。これはDAGを実装する際の私たちの北極星でした。私たちがsimpleSAMLphpをビルディングブロックとして選択した理由です。PHP、特に当時、セキュリティの記録で知られていたわけではありませんでしたが、simpleSAMLphpの評判はそれ自体で語っていました。誰もそれが何であるか本当によく知らなかった当時、simpleSAMLphpはXSWに対して回復力がありました。 simpleSAMLphpのセキュリティ記録（出典：On Breaking SAML） この2012年の論文で前面に出ていたにもかかわらず、XSWは今日でも存在します。バグクラスを知っているなら、なぜ修正できないのでしょうか？しかし、SAMLの欠陥に入る前に、まずそれが構築された shaky ground、つまりXMLを考慮する必要があります。 XMLは、セキュリティ記録（またはその欠如）に関して決して控えめではありません。これらのバグクラスは90年代の開発者にはより馴染み深かったかもしれませんが、それでもXMLには今日でも存在します。XXE、エンティティ展開（「ビリオンラフ」）、DTD取得（SSRF）、XPath/XQuery/XInclude/XSLT/CDATAインジェクションなどです。SAMLライブラリは、実際のSAML機能に到達する前に、これらのすべてのバグクラスを処理する必要があります。 セキュリティバグクラスに加えて、JSONのようなものと比較した場合のXMLの単純さの欠如もあります。XMLには、タグ、要素、属性、コメント、名前空間、マークアップ対コンテンツ、スキーマ、CDATA、DOCTYPEなどがあります。JSONには、基本的にキー、値、オブジェクト、リストがあります。複雑さは一般的にセキュリティと対立しており、これが私がSAMLを悪しき設計のフラクタルと見なす理由の1つです。 悪しき設計のフラクタル SAMLは、プロトコル設計について学ぶための十分な機会を提供します。このセクションでは、SAMLの認証プロトコルとしての長期的な実行可能性を致命的だと私が考える5つの欠陥について説明します。これらの欠陥は、新しい認証プロトコルを設計する際にも使用できます。つまり、欠陥を回避するか、その逆を取り入れてプロトコルに組み込もうとすることができます。 XML上に構築 前述のように、SAMLはXML上に構築されており、XMLは複雑ですが、それは委員会のせいではありません。XMLは当時彼らが持っていたものであり、人々が使用していたものです。JSONは2001年に「発見」されましたが、これはSAML委員会が会議を行っていた時期であり、実験的な新しいフォーマットを中心に認証プロトコルを設計する可能性は低いでしょう。特にそれがJavaScriptに対応しており、あなたが多くのJavaを書いている場合。 XMLとJSON、またはSAMLとJWT/OIDCの定量的な複雑さの測定（例：仕様/RFCの単語数、仕様/RFCの規範的な単語数など）を設計することは可能ですが、それには別のブログ記事または論文が必要になります。トピックから外れないように、ここではそれを控えます。XMLはJSONのようなものよりもはるかに複雑であると言えば十分でしょう。 正規化（Canonicalization） 正規化（C14N）とは、XMLというワイルドな混乱を取り、そのハッシュを計算し、一貫した結果を得たいときに実行することです。言い換えれば、SPとIdPが一貫したXMLデータ表現に合意できない場合、バイトが一致せず、署名が一致せず、認証が失敗します。しかし、これは言うは易く行うは難しです。 正規化のバグは、2018年のKelbyのXMLコメントバイパスを可能にしました。 XML正規化（出典：Identity Theft） 正規化は、多くの場合、パーサーの差分や「ラウンドトリップ」バグの前兆となります。これらは、ほとんどの最新のSAML攻撃が利用するものです。 Goの標準ライブラリにおけるXMLラウンドトリップ脆弱性の協調開示（2020年） XML実装のセキュリティ強化