ruby-saml：署名とデータを切り離すXML解釈差

何が起きたか・対象

ruby-samlで、署名を確認する処理とログイン対象を選ぶ処理に、同じXML内の異なる要素を使わせる認証回避がありました。識別子はCVE-2025-25291、CVE-2025-25292です。

攻撃者は対象組織で有効な署名付きアサーションを一つ持つことなどが条件です。XMLのDOCTYPEや名前空間を変更すると、REXMLとNokogiriが別々の要素を選ぶ場合がありました。有効な署名の確認には成功しても、本人情報との比較に署名で守られていないハッシュを使うと、署名された情報とログインするユーザーIDの結び付きが失われます。受信サービスは別ユーザーとしてセッションを発行するおそれがあり、暗号署名そのものを偽造した問題ではありません。ここでのアサーションは、ユーザーIDなどを含むSAML応答内の本人情報です。署名付き情報は対象組織で有効なものなら非管理者のものでも条件を満たす場合があり、なりすます相手の情報そのものの署名を偽造する必要はありません。

報告・修正・公開の時系列

1.17.0を対象に検証され、2024-11-14に二つの問題が報告されました。2025-03-12に修正版が公開され、研究アドバイザリは09-11に公開されています。

正常ならどう動くはずだったか

組織の認証サービスIdPが、ログインした利用者の情報をSAML応答へ入れて署名します。ブラウザ経由で受け取るサービスの中で、ruby-samlがその応答を検証します。署名付きアサーションでは、本人情報から計算したハッシュとDigestValueを照合し、そのDigestValueを含むSignedInfoの署名も検証します。

二つの照合が同じデータを結び付けることが必要です。署名が正しいSignedInfo内のハッシュと、実際にログインへ使う本人情報から計算したハッシュが一致すれば、両者の対応を確認できます。別々のSignedInfoから比較値を選ぶと、その保証は失われます。

技術的な原因

ruby-samlは、Nokogiriで本人情報を選んで正規化・ハッシュ計算し、その結果をREXMLが選んだDigestValueと比較していました。署名の照合には、Nokogiriが選んだSignedInfoと、REXMLが選んだSignatureValueを使います。同じXMLでも二つの解析器が別のSignature要素を選ぶと、二つの照合のつながりが失われます。

攻撃者は有効なSignedInfoと署名の組を残しつつ、採用させたい本人情報と、その内容に合うハッシュも用意します。署名検証は元の有効な組で成功し、本人情報の比較は攻撃者が変更できる別のDigestValueで成功する構成なら、本人情報を保護する署名がなくてもログインが許可されます。

DOCTYPEはXMLの文書型を宣言する構文、名前空間は同じ要素名を識別する仕組み、XPathは要素を選ぶ指定です。本件はDOCTYPEや名前空間の扱いの差で、同じXPathがREXMLではSignature A、NokogiriではSignature Bを選ぶ状態を作れる問題です。各CVEの完全なXML再現はここでは行わず、二つの要素を選んだ後の照合の不一致を示しています。

攻撃が成立する条件と流れ

攻撃者が対象組織の検証鍵で有効な署名付きアサーションを一つ持つことなどが条件です。その署名を残しつつ、解析器によって別の要素を選ばせるXML応答を作り、受信側へ送ります。署名検証を通ったことを根拠に、別のユーザーIDも正規の本人情報として採用されると、攻撃者の操作に別人のログイン状態が与えられます。

確認された事実と、想定される影響

研究は認証回避を実証しています。一般的な影響例では、別人として発行されたセッションを攻撃者がHTTPリクエストへ含めると、その利用者向けの文書や設定をサーバーから取得できるおそれがあります。取得できる範囲は、なりすましたアカウントの権限と個々の認可に従います。暗号署名そのものを偽造したわけではなく、GitHubの試験環境での報告と、本番侵害・実悪用も区別します。

実際の修正・対応方針

初回対応は1.18.0などで、ハッシュと署名対象の結び付きを修正しました。最初から二つの解析器を廃止したという対応ではなく、互換性を保つ修正でした。後続の別問題も含め、利用系列の開発元案内を確認します。

利用者・運用者が確認すること

直接のruby-saml依存に加え、omniauth-samlなど経由の利用も調べ、サポートされる修正済み版へ更新します。設定したIdPの鍵と、検証後に採用するユーザーIDの対応も確認します。連携設定では信頼するIdPと検証鍵を確認し、コードでは検証済みデータから採用するユーザーIDまで追います。署名の検証に使ったSignedInfo内のハッシュと、実際に採用する本人情報が対応することを、ライブラリの返却値と利用側の処理で確かめます。

開発者への教訓（教材としての考察）

署名の計算が正しいことだけでは不十分です。「検証した署名が、実際に採用するデータを守っているか」を、解析器と要素の選択をまたいで確認する必要があります。

出典・確認範囲

[1] Authentication bypasses in ruby-samlGitHub Security Lab / 確認日 2026-10-29
[2] Sign in as anyone: Bypassing SAML SSO authentication with parser differentialsGitHub Blog / 確認日 2026-11-01

未確認事項・限界

参照資料では実悪用や実際の被害件数を確認できません。未記載の実装差分は推測していません。