SAML.

SAML(Security Assertion Markup Language)は、2005 年に OASIS SAML 2.0 として標準化されたもので、信頼できる ID プロバイダ(IdP) が利用者の身元と属性を記述したデジタル署名付きの XML アサーションを サービスプロバイダ(SP) に発行し、セキュリティドメインを越えた Web シングルサインオンを実現する仕組みを定義します。SAML 2.0 は HTTP-Redirect と HTTP-POST のバインディングをサポートします。SP はセッションを生成する前に、アサーションの XML 署名、Audience、NotOnOrAfter の時刻条件、InResponseTo を検証しなければなりません。

攻撃と弱点

主に 2 つの障害クラスがあります。XML 署名ラッピング(XSW) とコメントインジェクションのバグにより、攻撃者は署名検証をすり抜けて攻撃者が制御するデータを紛れ込ませることができます。2018 年 2 月、Duo Labs は主要なツールキット全体にまたがるこの種の広範な欠陥を公表しました――CVE-2017-11427(python-saml)、CVE-2017-11428(ruby-saml)、CVE-2017-11429(saml2-js)、CVE-2017-11430(omniauth-saml)――これらは NameID に挿入された <!-- --> コメントが解析される Subject を切り詰め、認証済みの利用者が別人としてログインできてしまうものでした。Golden SAML は 2017 年に CyberArk が説明したもので、侵害後の攻撃です。AD FS のトークン署名用秘密鍵を盗んだ攻撃者は、パスワードや MFA を回避する任意のアサーションを偽造できます。APT29 は 2020 年の SolarWinds/SUNBURST キャンペーンでまさにこれを用い、通常のサインインに見えるフェデレーショントークンを生成しました。

防御策としては、レスポンス と アサーションの両方に署名を強制すること、厳格な Audience/Recipient チェック、トークン署名用鍵のハードウェア保護(HSM)、その鍵のローテーション、異常なフェデレーションログインの監視などがあります。新規連携では OpenID Connect が選ばれることが多くなっています。

flowchart LR
  U[利用者のブラウザ] -->|1 リソースにアクセス| SP[サービスプロバイダ]
  SP -->|2 AuthnRequest リダイレクト| IdP[ID プロバイダ]
  IdP -->|3 利用者を認証| IdP
  IdP -->|4 署名付き SAML アサーション| U
  U -->|5 アサーションを POST| SP
  SP -->|6 署名と条件を検証| SP
  SP -->|7 セッション付与| U