XML署名のパッケージングとは。
XML署名パッケージング（XSW）は、XMLベースのセキュリティー・プロトコル、特にSecurity Assertion Markup Language（SAML）、Simple Object Access Protocol（SOAP）、およびWeb Services Security（WS-SecurityまたはWSS）を使用するアプリケーションでXML署名が検証される方法をエクスプロイトするサイバー攻撃の一種です。
IBMニュースレター
The DX Leaders
AI活用のグローバル・トレンドや日本の市場動向を踏まえたDX、生成AIの最新情報を毎月お届けします。登録の際はIBMプライバシー・ステートメントをご覧ください。
ニュースレターは日本語で配信されます。すべてのニュースレターに登録解除リンクがあります。サブスクリプションの管理や解除はこちらから。詳しくはIBMプライバシー・ステートメントをご覧ください。
Extensible Markup Language（XML）は、人間が読み取れるものと機械が読み取れる方法でデータを構造化および保管するために使用されるテキストベースのデータ形式です。Webサービス、IDシステム、アプリケーション間のデータ交換で使用されます。
HTMLと同様、XMLはデータを表すように設計されたタグで構造化されています。ネストされた要素と属性をサポートし、複雑な階層を可能にします。
XMLは、SOAP、SAML、およびWS-Securityプロトコルでよく使用されます。
XMLの例
XML署名は、W3C XML署名仕様で定義されている、XMLデータに適用されるデジタル署名です。XML署名要素は、データが信頼でき、検証可能であり、改ざんされていないことを主張することで、データの整合性を確保するのに役立ちます。
- XMLドキュメントの一部が署名のために選択するには、
<Reference> ID（例：#ID123）を持つ要素を使用します。
そのデータについてハッシュまたはダイジェストが計算されます。
ハッシュは送信者の秘密鍵で暗号化され、署名を形成します。
A
<Signature> ブロックが、参照URI、暗号化ハッシュのSignatureValue、公開鍵や証明書などのKeyInfoを含むSignedInfoを使用して文書に追加されます。
XML署名の構文の例
<!-- Other details like DigestMethod, CanonicalizationMethod -->
IBMお客様事例
お客様のビジネス課題（顧客満足度の向上、営業力強化、コスト削減、業務改善、セキュリティー強化、システム運用管理の改善、グローバル展開、社会貢献など）を解決した多岐にわたる事例のご紹介です。
XML署名のパッケージング攻撃は、XMLの構造の柔軟性をエクスプロイトし、アプリケーションをだまして未認証のデータを処理させながら、署名の検証に合格させます。攻撃者は、署名された要素と実際に処理された要素（通常、要素を複製または再配置することによって）の間に不一致を作り出します。その結果、署名が有効に見えても、アプリケーションは未署名のコンテンツを使用しています。
XML署名パッケージング（XSW）攻撃の通常の仕組みは次のとおりです。
攻撃者は、デジタル署名された有効なログイン応答（正当なSAML応答など）など、実際の信頼できるXMLメッセージから始めます。
署名された部分（参照されている箇所
<ds:Reference URI=”#ID123”/> ）を、文書内の別の場所へ移動します。その部分自体は技術的には文書内に存在し続けていますが、実際には使用されません。
彼らは偽造されたデータを元の場所に配置します。この偽造データは署名されていませんが、正当なものに見えるように作成されています。
ほとんどのアプリケーションは、署名されたバージョンかどうかを確認するのではなく、タグ名やXPath表現によってデータを検索するため、最終的に偽造されたデータを使用することになります。
デジタル署名は、アプリが使用する偽造された部分ではなく、元の（現在は隠されている）署名された部分を検証しているため、検証されます。
つまり、アプリケーションは安全な署名付き文書を扱っていると認識していますが、実際には不正に操作された無許可のデータに対して動作しています。
チュートリアル：実際のXSW攻撃
この例は、攻撃者が署名されたSAMLアサーションを操作して、弱いXML解析と検証ロジックをエクスプロイトすることで、不正な管理アクセスを取得する方法を示しています。
SAMLは、アイデンティティプロバイダー（IdP）とサービス・プロバイダー（SP）という2つのシステム間で認証情報を安全に交換するために使用されるXMLベースのプロトコルです。シングル・サインオン（SSO）が有効になり、ユーザーは一度認証するだけで、繰り返しログインすることなく複数のサービスにアクセスできるようになります。
1. オリジナルのSAMLリクエスト
これは、BurpスイートのSAML Raiderなどのツールによってキャプチャーされた本物のSAMLリクエストです。これには、ユーザーのIDの詳細を含む、SAMLアサーションと呼ばれるデジタル署名セクションが含まれています。このアサーションの中でも
リクエストには有効なデジタル署名（
2. ログインしたユーザーを観察する
アプリの応答では、ユーザーが元のフィールド
3. 修正されたSAMLアサーション（XSW攻撃の実行）
攻撃者は、デジタル署名された元のアサーションをXMLドキュメントの別の部分に移動することでSAMLリクエストを密かに変更し、署名が有効なままで検証を合格できるようにします。
その後、
このアクティビティーは、XSW攻撃の中核となる概念を示しています。デジタル署名は有効に見えますが、アプリケーションによって処理されたデータは偽物であり、信頼できません。
4. 管理アクセスの成功
結果として、アプリケーションは攻撃者によって注入された偽のアサーションに基づいて管理アクセスを許可します。アサーションが実際にデジタル署名されたものであるかどうかを検証することはできません。この失敗により、攻撃者は管理ユーザーになりすますことができます。ユーザーがadmin@libcurl.soとしてログインできるシステムは、XMLシグネチャ・パッケージング攻撃が成功したことを明確に示します。
この例では、脆弱なXML署名チェックをだまして偽のデータを信頼させることができます。攻撃者はデジタル署名を破ることはありません。代わりに、署名されたデータは他の場所に移動され、アプリが実際のデータを予想する場所に偽の情報が配置されます。その後、アプリケーションは偽のデータを安全であると信じて誤って処理します。
XSW攻撃は通常、いくつかの主要なサブセットまたはタイプに分類され、それぞれがXML署名の検証と解析の実装方法をエクスプロイトします。
最も一般的なものは次のとおりです。
1. シンプルなパッケージング攻撃
手法：攻撃者は、署名された要素をXMLドキュメントの別の部分に移動させ、悪意のある要素を元の場所に挿入します。
目標：署名は（署名されたデータが変更されないため）Verifyされますが、アプリケーションは代わりに攻撃者が注入したデータを処理します。
例：署名済み
2. IDベースのパッケージング
方法：攻撃者は、署名されたデータを参照するためにXML ID属性の使用をエクスプロイトします。
目標：攻撃者は同じIDを持つ重複要素を作成しますが、それをアプリケーションが最初に処理する場所に配置します。
例例：署名は#ID-1234を参照していますが、パーサーはそのIDを持つ攻撃者の偽のエレメントを、署名されたものの代わりに使います。
3. 名前空間インジェクションのパッケージング
方法：攻撃者はXML名前空間を操作し、署名検証を混乱させます。
目標：署名を有効に保ちながら、要素の解釈を変更したり、厳密なスキーマ・チェックを回避したりします。
例：悪意のある<Assertion>要素を新しい名前空間に注入して、検証はパスするが処理ロジックはそれを受け入れるようにします。
4. エンベロープ署名の悪用を伴うXSW
方法：署名済みXML内の配置を変更し、
目標：検証者にすべてが署名されていると考察させますが、攻撃者が管理する部分は署名の対象範囲から除外します。
例：元の
5. XPathインジェクション・パッケージング
方法：署名の検証中に使用されるXPathクエリを操作して、署名されたノードではなく攻撃者が制御するノードを指します。
目標：アプリケーションが悪意のあるデータを処理している間、署名検証ツールをだまして無害なデータをチェックさせます。
例：XMLを調整し、検証者のXPath（例：
XSW攻撃は、特に機密データやクリティカルなオペレーションが関係する場合、現実世界の深刻な結果につながる可能性があります。これらの仮定シナリオは、そのような攻撃の潜在的な影響を浮き彫りにしています。
シナリオ1：SAML SSOでの認証のバイパス
シナリオ：エンタープライズ・アプリケーションは、SAMLベースのシングル・サインオンを使用してユーザーを認証します。各ログイン応答には、ユーザーを識別するデジタル署名されたSAMLアサーションが含まれます。
XSW攻撃：攻撃者は正規のSAML応答をキャプチャーし、署名されたアサーションをXMLドキュメントの別の部分に動き、偽造されたアサーションを挿入します。
影響：システムは元のアサーションの署名を検証しますが、署名されていない攻撃者が注入したアサーションを処理し、脅威アクターに特権ユーザーとしてのアクセスを与えます。
シナリオ2：Webサービスでの特権昇格
シナリオ：Webサービスアプリケーション・プログラミング・インターフェース（API）は、SOAPとWS-Securityを使用して要求を処理します。SOAPメッセージ本文は、コマンドの信頼性を保証するためにデジタル署名が行われます。
XSW攻撃：攻撃者は、オリジナルの署名付きSOAP本文を無害なラッパー要素でラップし、昇格特権や不正なアクションを含む新しい署名なし本文に置き換えます。
影響：サービスが署名されていない本文を処理する場合、攻撃者は権限を昇格させたり、機密データの表示や変更などの制限されたアクションを実行したりする可能性があります。
シナリオ3：クリティカルな機能への不正アクセス
シナリオ：管理インターフェースから、ユーザーは、アカウントの削除やパスワードのリセットなど、デジタル署名で保護されたXMLベースのコマンドを送信できます。
XSW攻撃：攻撃者は署名されたコマンドをセカンダリの場所に動きさせ、その場所に署名されていないコマンド（別のユーザーのアカウントの削除や管理者のパスワードのリセットなど）を挿入します。
影響：アプリケーションが署名されていないコマンドを処理すると、権限のないユーザーに代わってクリティカルなオペレーションを実行する可能性があります。
シナリオ4：デジタル署名された支払い要求の操作
シナリオ：ある銀行は、XML署名を使用することで資金振替オペレーションを保護しています。各リクエストには、送金額や送信者と受信者の口座番号などのトランザクションの詳細が含まれます。リクエストはデジタル署名され、信頼性が確保されます。
XSW攻撃：XSW攻撃：攻撃者は有効な送金リクエストを捕捉し、署名されたデータをドキュメントの重要でないセクションに移し、より大きな金額と異なる受取人アカウントを持つ偽造トランザクションを挿入します。
影響：アプリケーションが、処理されたトランザクションが、署名されていることを厳密に確認できない場合、攻撃者が偽造したトランザクションを実行し、不正な送金や金銭的損失を引き起こす可能性があります。
シナリオ5：署名付き認証トークンの改ざん
シナリオ：オンラインプラットフォームは、XMLデジタル署名を使用してトークンを保護します。各トークンにはユーザーID情報とアクセス権が含まれており、改ざんを防ぐために暗号署名されています。
XSW攻撃：攻撃者は有効な認証トークンをキャプチャーし、署名された部分をXML内の別の場所に移動し、昇格された特権または無許可の権限を含む新しい署名のないセグメントを挿入します。
影響：サーバーが署名されたセクションではなく操作されたセクションを処理すると、攻撃者は不正アクセスを取得したり、特権のオペレーションを実行したりして、アプリケーションのセキュリティーが侵害される可能性があります。
アプリケーションがXML署名パッケージング攻撃に対する脆弱性があるかどうかを分析するには、アプリケーションがXMLデータをどのように解析および処理するかを理解することが重要です。SAML認証やSOAPメッセージングなどのセキュリティーに配慮したコンテキストでのXML解析と処理を理解することが特に重要です。
実際の環境でこのような脆弱性を特定するための手法とストラテジーをいくつか紹介します。
1. アプリケーションがXMLを解析する方法を分析する
アプリケーションが、実際に署名された要素であることを確認する代わりに、
2. BurpスイートSAMLレイダーまたはカスタム・プロキシーを使用する
BurpスイートとSAML Raiderを使用して、偽の署名されていない要素を挿入し、署名された要素をラップします。署名が検証されている間にアプリが偽のデータを処理した場合、それはXSWに対して脆弱になります。
3. 同じタグを持つ重複要素をテストする
署名されたアサーションを隠したセクションに、偽のアサーションを目に見える場所に挿入します。アプリが偽のデータを処理する場合、XSWに対して脆弱になります。
4. 署名の参照動作を確認する
署名された要素（署名された要素
アプリケーションが実際に署名されたバージョンではなく、署名されていないバージョンを処理した場合、アプリケーションはXSW攻撃に対して脆弱になります。アプリは署名を正しく検証していますが、署名されたコンテンツを使用していることの確認に失敗し、攻撃者が不正なデータを注入される可能性があります。
5. エラー処理とロギングの動作を確認
不正なアサーションを送信し、詳細なエラーや一貫性のない応答をモニタリングします。これらの応答により、アプリのXMLセキュリティーと検証ロジックの弱点が露呈する可能性があります。
6. 既知のXSWエクスプロイテーション手法をテストに活用する
SAML Raider、SoapUI、またはカスタムXMLテスト・ハーネスなどのツールを使用して、XSW攻撃パターンを適用します。アプリケーションがペイロードのいずれかを受け入れて処理した場合は、XSW脆弱性を示しています。
7. アプリケーションコードの検査
アプリが署名された信頼できる要素を使用していることを確認せずにタグ名に基づいて要素をピッキングしてXMLデータを読み取ると、偽のデータを処理させることができます。
アプリケーションをXSW攻撃から保護するために、開発者は厳密なXML処理を実装し、署名を正しく検証し、信頼できる署名済みデータのみが使用されるようにできます。
XSW攻撃からの防御に役立つ具体的な対策は次のとおりです。
認証または承認に使用されているXML要素が、デジタル署名されたものと正確に同じであることを確認します。そうすることで、攻撃者が、アプリケーションが正当な署名されたアサーションではなく誤って処理される可能性があるという、未署名の二番目のアサーションを注入するのを防ぐことができます。
エンベロープ署名は、署名する要素の内部に配置された署名です。エンベロープ処理により、攻撃者が構造を壊すことなく、署名されたコンテンツの外側に悪意のある要素を挿入することがより困難になるため、パッケージングや置換の防止に役立ちます。
重複したID、外部エンティティーへの参照、または予期しない構造を持つドキュメントを拒否するように構成された安全なXMLパーサーを使用します。XSWは、重複するタグや複数のアサーションを挿入するなど、XML構造の操作に依存しています。厳密な解析により、整形式のスキーマ準拠のインプットを強制することで、この攻撃対象領域が縮小されます。
アプリケーションの処理ロジックを、署名内で参照されているXML要素に直接結び付けます（ID属性または署名
明示的に要求されていない限り、複数の<Assertion>を含むSAML応答を拒否します。XSW攻撃では、多くの場合、2番目のアサーションが挿入されます。1つだけ処理されるようにすると、曖昧さが解消され、リスクが軽減されます。
安全なデフォルト構成を備えたXMLデジタル署名検証（Apache SantuarioやOpenSAMLなど）には、メンテナンスが行き届いた、セキュリティーに配慮したライブラリーを使用します。これらのライブラリーには、適切に構成された場合、シグネチャのパッケージングに対する保護機能が組み込まれていることがよくあります。
受信SAMLアサーションを公式のSAML XMLスキーマ定義（XSD）に照らして検証します。検証により、攻撃者がビジネス・ロジックを迂回したりXMLパーサーを混乱させたりする予期せぬ要素や属性を注入することを防ぎます。
署名されたXML（アサーションなど）で使用される各ID属性が一意であり、参照が1つの要素のみに一致することを確認します。XSWエクスプロイトは、署名内の1つの要素を参照しながら、同じIDまたはタグ名を持つ別の要素を挿入することで成功する可能性があります。一意性を強制することで、この混乱を回避できます。
これらの対策により、攻撃者がXML構造と署名処理ロジックをエクスプロイトするリスクを軽減でき、多くのXSW攻撃に対する扉を効果的に閉じることができます。