こんにちは！セキュリティ対策に日々奮闘されている新人IT担当者の皆さん、そして開発者の皆さん、お疲れ様です。
皆さんは、会社のシステムやクラウドサービス（例えばMicrosoft 365やGoogle Workspaceなど）にログインするとき、「会社のアカウントで一発ログイン（シングルサインオン）」を使う機会が増えているのではないでしょうか？
IDとパスワードを何度も入力しなくて済むのでとても便利ですよね。この便利な仕組みの裏側で、こっそりと主役に据えられているのが「SAML（サムル）」という技術です。
今回は、このSAMLの仕組みに潜むちょっと怖い「XML Signature Wrapping（XML署名ラップ）攻撃」というサイバー攻撃の手口と、それを防ぐための大切なポイントについて、身近な「家の鍵と合鍵」の防犯にたとえながら、優しく紐解いていきたいと思います。
一歩ずつ、安心して学んでいきましょう！
—
1. 身近な例えで理解する「SAML」と「身分証明書」
まず、SAMLが普段どうやって動いているのかを、マンションのオートロックシステムに例えてみましょう。
- ユーザー（あなた）: マンションの住人
- サービスプロバイダー（SP）: あなたが入ろうとしているお部屋のドア
- アイデンティティプロバイダー（IdP）: フロントにいる信頼できる管理人さん
あなたがドア（SP）を開けたいとき、直接ドアに合鍵を差し込むのではなく、まず管理人さん（IdP）のところへ行って「私は〇〇号室の住人です！」と伝えます。
管理人さんはあなたの顔を確認すると、「この人は間違いなく〇〇号室の住人です。管理人室のハンコを押しておきますね」と書かれた「身分証明書（これがSAMLアサーションです）」を渡してくれます。
あなたはドアの前に戻り、その身分証明書を提示します。ドアは「管理人さんのハンコが本物だから、入ってよし！」と判断して鍵を開けてくれます。これがSAML認証の流れですね。
—
2. 泥棒の手口：XML Signature Wrapping（XSW）攻撃とは？
さて、ここで悪巧みをする泥棒（攻撃者）が登場します。
泥棒は、管理人さんが押してくれた「本物のハンコ（デジタル署名）」を盗み出すことはできません。なぜなら、デジタル署名は非常に強力な暗号技術で守られているからです。
そこで泥棒は、「書類のすり替え」というズルい手を使います。これが XML Signature Wrapping（XSW：XML署名ラップ）攻撃 の正体です。
巧妙な「書類のすり替え」の仕組み
SAMLのやり取りで使われるデータは、「XML」という形式で書かれています。XMLは、まるでロシアのマトリョーシカ人形のように、タグの中に別のタグを入れ子構造でどんどん詰め込めるのが特徴です。
泥棒は、次のような悪巧みをします。
1. 管理人さんからもらった「本物のハンコが押された本物の身分証明書（A）」を手に入れます。
2. その中に、自分が勝手に書いた「私は管理者です！」という偽物の身分証明書（B）」をこっそり忍び込ませます。
3. システムに提出する際、「審査するのは、新しく追加したほう（B）の身分証明書を見てくださいね！」とプログラムを誘導します。
プログラムの作りが甘いと、「ハンコ（デジタル署名）が本物かどうか」だけを確認して、「肝心の身分証明書の中身（誰がログインしようとしているか）」をすり替わった偽物のほうで判断してしまうという重大なミスを起こしてしまいます。
結果として、泥棒は「管理人さんのハンコ」を盾にして、システムに不正侵入することに成功してしまうのです。これが、XML Signature Wrapping攻撃の恐ろしいメカニズムです。
—
3. なぜこの脆弱性が生まれてしまうのか？
開発現場でよくある原因は、次のような思い込みです。
> 「デジタル署名がちゃんと検証できているから、中身のデータも絶対に安全なはずだ！」
実は、「署名の正当性（ハンコが本物か）」と「XMLのツリー構造（書類のどこを読むべきか）」は、プログラム上では別々に処理されることが多いのです。
攻撃者は、この「人間なら一目で気づく矛盾」を突いて、プログラムが読み取る順番や場所を巧みに混乱させます。
—
4. 実務で使える！堅牢なSAML検証の実装と設定のポイント
「じゃあ、どうやってこの攻撃からシステムを守ればいいの？」という不安になりますよね。
ここからは、実際の開発やインフラ構築で私たちが取り組むべき具体的な対策を見ていきましょう。
対策①：SAMLライブラリは「自作せず、枯れた実績のあるもの」を使う
SAMLのXMLパース（読み込み）や署名検証を自前で実装するのは、地雷原を裸足で歩くようなものです。必ず、世界中で検証され尽くした信頼性の高いライブラリ（例: OneLogin PHP SAML Toolkit や Spring Security SAML など）を使用してください。
対策②：署名対象の要素（Reference URI）を厳格に固定する
SAMLレスポンスの中にあるデジタル署名には、「どの部分のデータに対して署名をしたか」を示す Reference URI という場所が指定されています。
ここが曖昧だったり、任意の場所を指すようになっていると、XSW攻撃の餌食になります。
次のように、署名が「アサーション自体のID」を正確に指しているか、プログラム側（またはライブラリの設定）で厳格にチェックさせます。
// PHP（SAMLライブラリの設定例）のイメージ
$settings = [
// ... その他の設定 ...
'security' => [
// 署名のないSAMLレスポンスやアサーションを一切拒否する
'wantXMLSignatures' => true,
// アサーション（身分証明書）自体の署名を必須にする
'wantAssertionsSigned' => true,
// 厳密なダイジェストアルゴリズムを指定（古いSHA-1などは禁止）
'signatureAlgorithm' => 'http://www.w3.org/2001/04/xmlenc#sha256',
]
];対策③：タイムスタンプ（有効期限）の厳格なチェック
泥棒が過去に誰かから奪った「本物の身分証明書」を使い回す「リプレイ攻撃」を防ぐため、タイムスタンプの確認も欠かせません。
SAMLアサーションには、以下の情報が含まれています。
NotBefore（この時間より前は無効）NotOnOrAfter（この時間を過ぎたら無効）
サーバー側の時計が狂っていると、有効な証明書が弾かれたり、逆に古い証明書が通ってしまったりします。NTP（ネットワーク・タイム・プロトコル）を用いて、必ずサーバーの時刻を正確に同期させておくことが、セキュリティの第一歩になります。
<!-- SAMLアサーション内のタイムスタンプの例 -->
<Conditions NotBefore="202X-10-01T12:00:00Z" NotOnOrAfter="202X-10-01T12:05:00Z">
<!-- 有効期間がたったの5分間に制限されていることで、不正利用のリスクを減らします -->
<AudienceRestriction>
<Audience>https://your-company-app.com/saml/metadata</Audience>
</AudienceRestriction>
</Conditions>—
まとめ
いかがでしたでしょうか？
今回は、SAMLアサーションの裏側に潜むXML Signature Wrapping攻撃の仕組みと、その対策についてご紹介しました。
- SAMLは便利な半面、XMLの複雑な構造を突いた「すり替え攻撃（XSW）」のターゲットになりやすい。
- 「ハンコ（署名）が本物か」だけでなく、「読んでいる書類の場所（要素）」が正しく意図されたものかを確認することが重要。
- 脆弱性対策済みの信頼できるライブラリを使い、厳格な設定と正確な時刻同期（NTP）を行う。
セキュリティの世界は一見すると難しく感じられますが、「誰が・何を・どうやって確認しているか」という基本の仕組みを紐解いていけば、必ず確実な対策が見えてきます。
今回の知識が、皆さんのシステムをより安全にするための小さな盾となれば幸いです。一緒に一歩ずつ、セキュアな開発スキルを磨いていきましょう！
コメント