XXE脆弱性ガイド2025：XML攻撃の現状と対策

iframe width=“560” height=“315” src=”https://www.youtube.com/embed/z3OKr4gTE-E” title=“YouTube video player” frameborder=“0” allow=“accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture” allowfullscreen/iframe

はじめに：「古い」脅威が死なない理由

サイバーセキュリティの急速な進化の中で、新たな脆弱性が日々登場する一方、XML External Entity (XXE)インジェクションは、レガシーな脅威も最新の攻撃と同じくらい危険であることを思い出させるものです。10年以上にわたり詳細に記録されてきたにもかかわらず、2025年現在もXXEの脆弱性は現代アプリケーションを脅かし続けており、最近の高 profilな発見は、大手テクノロジー企業も免れていないことを示しています。

2025年初頭、セキュリティ研究者はAkamai CloudTestにおいて、攻撃者がサーバーファイルにアクセスし、/etc/passwdなどの機密データを抽出できる重大なXXE脆弱性を発見しました。同様に、CVE-2025-23195はAmbari/Oozieプロジェクトにおいて、任意のファイルを読み取ったりサーバー側リクエストフォージェリ（SSRF）攻撃を行ったりできるXXE脆弱性を明らかにしました。これらの最近の事例は、組織が未だに不安全なデフォルト設定のXMLパーサーを導入し続けている現実を浮き彫りにしています。これにより、攻撃を防げたはずの脆弱性が放置されています。

XXEの理解：技術的な深掘り

XXEインジェクションとは何か？

XML External Entityインジェクションは、XMLパーサーが外部エンティティを処理する仕組みを悪用し、攻撃者がアプリケーションのXMLデータ処理に干渉できるウェブセキュリティの脆弱性です。外部エンティティは、Document Type Definition（DTD）外から値を読み込むカスタムXMLエンティティであり、ローカルファイルパスやURLを参照できます。

この問題の根底にはXML仕様自体の問題があります。XMLプロセッサは、外部エンティティの出現箇所をシステム識別子から取得した内容に置き換えます。アプリケーションがXMLパーサーの設定を適切に行わない場合、攻撃者はこの仕組みを操作して、保護すべきリソースにアクセスできます。

XXE攻撃の構造

基本的なXXEペイロードは、そのシンプルさと効果を示しています：

<?xml version="1.0"?>
<!DOCTYPE root [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<root>&xxe;</root>

XMLパーサーが適切なセキュリティ制御なしにこのペイロードを処理すると、外部エンティティが解決され、システムファイルの内容がXML出力に直接挿入され、OSレベルのデータが漏洩する可能性があります。

XXEの3つの柱

1. ファイル開示攻撃：情報の宝庫

ファイル開示攻撃は、攻撃者が悪意あるXMLエンティティを通じてローカルシステムのファイルにアクセスし、設定ファイルやパスワードファイル、アプリケーションのソースコードなどの機密情報を明らかにします。この能力は、一見単純なパースの脆弱性を、システム全体の侵害に変えるものです。

攻撃者が狙う代表的なファイル例： - /etc/passwdや/etc/shadow（Unix系システム） - Windowsのレジストリキー - データベース資格情報を含むアプリ設定ファイル - クラウドのメタデータエンドポイント（AWS、Azure、GCP） - プライベートSSHキーやSSL証明書

単なるファイル読み取りを超え、攻撃者はローカルファイルを読み出し、その内容を遠隔サーバーに送信して情報漏洩を行うことも可能です。

2. サーバーサイドリクエストフォージェリ（SSRF）：内部境界の突破

XXEの脆弱性は、サーバー側のアプリケーションに対して任意のURLへのHTTPリクエストを誘発させるSSRF攻撃に悪用されることがあります。特にクラウド環境や内部ネットワークでは危険性が高まります。

この攻撃により、攻撃者は以下のことが可能です： - 内部ネットワークのインフラを調査し、システムをマッピング - クラウドのメタデータサービスにアクセスし、資格情報を盗む - ファイアウォールルールを回避し、制限された内部APIにアクセス - 外部向けシステムから内部リソースへピボット

GeoServerの最近のCVE-2025-30220は、XXEを利用してアプリケーションに内部または任意の外部システムへのHTTPリクエストをさせる例を示し、この攻撃ベクトルの重要性を再認識させました。

3. サービス拒否（DoS）：ビリオンドラッグ攻撃

“Billion Laughs”攻撃は、再帰的エンティティ宣言を利用し、解析中にエンティティを指数関数的に展開させ、大量のメモリを消費させてシステムをクラッシュさせるものです。この攻撃は、ペイロード自体は小さくても、展開時に膨大なリソースを消費し、サーバーを圧倒します。

典型的なBillion Laughsペイロードは、ネストされたエンティティ定義を指数関数的に展開します：

<!DOCTYPE root [
  <!ENTITY e "e">
  <!ENTITY e1 "&e;&e;&e;&e;&e;&e;&e;&e;&e;&e;">
  <!ENTITY e2 "&e1;&e1;&e1;&e1;&e1;&e1;&e1;&e1;&e1;&e1;">
  <!ENTITY e3 "&e2;&e2;&e2;&e2;&e2;&e2;&e2;&e2;&e2;&e2;">
]>
<root>&e3;</root>

この小さなペイロードは、解析時にギガバイト単位のメモリを消費し、運用環境を麻痺させる可能性があります。

なぜSOAP APIはXXEの温床なのか

SOAP-XMLの依存性

SOAP APIはほぼ例外なくXMLパーサーに依存しており、これがXXE攻撃やXPathインジェクションの脆弱性を生み出しています。JSONを主に使用する現代のREST APIと比べ、SOAPはXMLに厳格に従うため、攻撃対象の範囲が広がり、多くの組織が適切に保護できていません。

SOAPは金融、医療、政府などの重要なシステムで信頼性、監査性、トランザクションの整合性のために今なお利用されています。これらの高価値システムでの広範な利用は、SOAPエンドポイントを高度な攻撃のターゲットにしています。

Akamai CloudTestの事例

最近のCVE-2025-49493の発見では、/concerto/services配下の複数のSOAPエンドポイントがXXE攻撃に脆弱であることが判明しました。セキュリティ研究者は、このパス内のほとんどのエンドポイントが同じ脆弱性を共有していることを発見し、一つの設定ミスがサービスインフラ全体を危険にさらすことを示しました。

このケースは、次の点を示しています： - 体系的な露出：一つのSOAPエンドポイントの脆弱性が、複数のエンドポイントに波及する - 発見の遅れ：大手テクノロジー企業であっても、2025年まで脆弱性が放置されていた - 実世界への影響：攻撃者は機密サーバーファイルや環境変数にアクセス可能

最終的に、DTD処理を完全に無効化することで、XXE攻撃の根源を断ち切る対策が取られました。

レガシーシステムと技術的負債

多くのSOAP APIは、古いライブラリやフレームワークの上に放置されており、最後の更新から10年以上経過しているケースもあります。ドイツの個人健康記録システムにおけるXSW脆弱性の研究では、認証を回避できることも示されており、これらの脅威の実態を浮き彫りにしています。

これらは、次のようなシステムに深く入り込んでいるため、対策が難しいです： - 数百万の取引を処理するコアバンキングシステム - 患者記録を管理する医療システム - 複数の企業をつなぐサプライチェーン連携 - 置き換えが困難なレガシー政府システム

ファイルアップロード機能：見落とされがちな攻撃経路

SVGファイルとXXE

XMLを含むファイルフォーマットやXMLサブコンポーネントを使用する例として、SVGがあります。アプリケーションが画像のアップロードと処理を許可している場合、SVGフォーマットをサポートしていると、攻撃者は悪意のあるSVG画像を送信し、隠されたXXE攻撃面に到達できます。

悪意のあるSVGファイルは、正当な画像マークアップに偽装したXXEペイロードを含むことが可能です：

<?xml version="1.0" standalone="yes"?>
<!DOCTYPE test [ 
  <!ENTITY xxe SYSTEM "file:///etc/hostname"> 
]>
<svg width="128px" height="128px" xmlns="http://www.w3.org/2000/svg">
  <text font-size="16" x="0" y="16">&xxe;</text>
</svg>

このSVGを処理すると、機密ファイルの内容が画像内に表示され、検出が難しくなります。

セカンドオーダーXXE：遅れてくる脅威

セカンドオーダーXXEは、悪意あるペイロードが一旦保存され、その後に取得・実行される高度なバリアントです。これらは、非同期に動作するインポート/エクスポート機能で特に多く見られ、ユーザーが提供したXMLファイルがバックグラウンドで処理される場合に発生します。

この遅延実行モデルは、次のような課題を生み出します： - 伝統的なセキュリティテストでは脆弱性が検出されにくい - 攻撃ポイントと実行コンテキストが分離している - ペイロードがデータベースやファイルシステムに残存 - 攻撃の追跡が難しい

SVG以外のXMLベースのファイルフォーマット

DOCXやXLSXなどのXMLベースのドキュメントを処理するビューアやコンバーターも、XXEの標的となり得ます。これらの現代的なオフィスドキュメントは、XMLファイルを含むZIPアーカイブです。アプリケーションがこれらを適切に検証せずに抽出・解析すると、XXE攻撃に脆弱になります。

音声ファイルも例外ではなく、CVE-2021-29447のWordPressの例では、ID3ライブラリを用いたMP3ファイルのメタデータ解析にXXEが仕込まれていました。

なぜ2025年もXXEが続くのか：根本原因

デフォルトの脆弱なパーサー設定

ほとんどのXMLパーサーは、外部エンティティをデフォルトで処理します。これにより、悪意あるXML要素に埋め込まれたシステムコードが明示的に設定されていなければ実行されてしまいます。この「安全でないデフォルト」設計は、開発者がパーサーを積極的に堅牢化しなければならない状況を生み出しています。

見えないXML処理

一部のREST APIは、JSONだけを扱うと誤認しているにもかかわらず、XMLデータも受け入れる設定になっている場合があります。Content-Type: application/xmlを受け入れたり、自動的にフォーマット変換を行ったりすることで、攻撃者は気づかないうちにXXEの攻撃面を作り出しています。

複雑なアプリケーションアーキテクチャ

Webアプリケーションは、多数のコンポーネントを含み、それぞれにXMLパーサーが存在することもあります。どの部分がXMLを処理しているか把握しづらく、特定のサードパーティコンポーネントの設定にアクセスできないケースもあります。

現代のアプリケーションは、次のような構成を持つことが多いです： - 独自のXMLパーサーを持つ複数のマイクロサービス - サードパーティのライブラリやフレームワーク - ドキュメント化されていない古いコンポーネント - XML入力を受け付けるクラウドサービス

セキュリティ意識の誤認

XMLの構造的な冗長性は、一見安全に見えますが、実際にはXMLパースの複雑さが新たな攻撃面を生み出しています。内部のSOAPサービスが安全に動作していると思い込むのは誤りです。

組織の誤った前提例： - “JSONだけ使っているからXXEは安全” - “内部だけのXMLエンドポイント” - “外部エンティティは数年前に無効化済み”（すべてのパーサーを確認せずに） - “WAFがXXE攻撃を防ぐ”

高度なXXE技術：防御を回避する手法

ブラインドXXE

多くのXXEはブラインド型であり、アプリケーションがレスポンスに外部エンティティの値を返さないため、直接ファイル内容を取得できません。それでも、アウト・オブ・バンド技術を用いてデータを抽出したり、XMLパースエラーを利用して内部情報を漏らしたりすることが可能です。

外部DTDのバイパス

セキュリティフィルターがfile://プロトコルをブロックしている場合、攻撃者は外部DTDを宣言したファイルを用いてフィルタリングを回避できます。攻撃者は、脆弱なアプリケーションに対して、悪意のあるDTDファイルを読み込ませるために、外部サーバーにペイロードを置き、そのURLを指定します。

パラメータエンティティの悪用

パラメータエンティティは、通常の外部エンティティをブロックするフィルタを回避するために利用されることがあります。外部DTD内でパラメータエンティティを定義し、それを利用して最終的な攻撃ペイロードを構築します。

総合的な防御戦略

パーサーの堅牢化

XMLパーサーは、不要なDTD処理を無効にするなど、セキュリティを最優先に設定すべきです。多くのアプリケーションでは、DTD処理を完全に無効化するのが最も効果的です：

Javaの場合:

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
dbf.setFeature("http://xml.org/sax/features/external-general-entities", false);
dbf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);

.NETの場合:

XmlReaderSettings settings = new XmlReaderSettings();
settings.DtdProcessing = DtdProcessing.Prohibit;
settings.XmlResolver = null;

PHPの場合:

libxml_disable_entity_loader(true);

入力検証とサニタイズ

XMLスキーマ検証時に外部エンティティ宣言や疑わしいエンティティ参照をチェックし、期待されるフォーマットと一致しない場合は拒否します。信頼できるスキーマに対して検証を行うことが重要です。

ホワイトリストベースの検証例： - 許可されたXML構造を定義し、それ以外を拒否 - 処理前にDOCTYPE宣言を除去 - 信頼できるスキーマに対して検証 - エンティティ宣言を含むXMLを拒否

ネットワークレベルの制御

XML処理システムを内部の重要リソースから隔離するために、ネットワークのセグメント化を行います。これにより、XXE攻撃の影響を限定できます。具体的には：

XML処理サービスをDMZに配置
XMLパーサーからのアウトバウンド通信を制限
厳格な出口フィルタリング
cloud metadataエンドポイント（169.254.169.254）へのアクセスをブロック
不審なファイルアクセスやネットワークリクエストを監視

アプリケーションアーキテクチャの改善

Content Security Policies（CSP）を導入し、不正なリソースアクセスやXML処理の制限を行います。現代のアプリケーションは、次のような設計を推奨します：

可能な限りXMLの使用を減らし、JSONに置き換える
XML処理を専用の堅牢なサービスに分離
最小権限のアクセス制御を実施
定期的にXML処理ライブラリを更新
XML処理コードのセキュリティ監査を実施

開発パイプラインへの統合

XXE脆弱性のテストをCI/CDパイプラインに組み込み、新規コードの脆弱性導入を防ぎます。具体的には：

静的アプリケーションセキュリティテスト（SAST）で脆弱な設定を検出
動的アプリケーションセキュリティテスト（DAST）で実行時のXXEを検出
ソフトウェア構成分析（SCA）でXMLライブラリの脆弱性を追跡
XML処理部分のセキュリティコードレビュー
XXE脆弱性の自動回帰テスト

実例と最新のCVE事例

CVE-2025-49493：Akamai CloudTest

この脆弱性は、複数のSOAPエンドポイントで同じXXEの脆弱性が共有されていることを示し、攻撃者が環境変数やシステムファイルを抽出できる事例です。企業のSOAPインフラにおいてXXEのシステム的な脆弱性が存在することを浮き彫りにしました。

CVE-2025-23195：Apache Ambari

Ambari/Oozieプロジェクトにおいて、外部エンティティの解決を無効にせずXML入力を不適切に解析したためにXXE脆弱性が発生しました。このケースは、オープンソースの成熟したプロジェクトでもXXE脆弱性が潜在していることを示しています。

CVE-2025-30220：GeoServer WFSサービス

GeoServerのこの深刻な脆弱性は、GeoToolsライブラリ内のXMLスキーマの不適切な処理により、エンティティ解決制御を回避し、WFSエンドポイントを通じて攻撃ベクトルを生み出しました。広く展開されている地理空間サーバーに影響し、XXEの特定の応用範囲を示しています。

業界別の課題

医療システム

電子カルテのクラウド移行に伴い、患者プライバシー保護のための堅牢な認証とXMLセキュリティ対策が求められています。医療システムの特有の課題は：

古いHL7やFHIRのXML実装
HIPAA準拠のデータ保護
複数のサードパーティシステムとの連携
24時間体制の運用によるパッチ適用の制約

金融サービス

コアバンキングシステムは、信頼性とトランザクションの整合性を重視し、SOAPを用いた複雑な取引を処理しています。金融機関は次の点に注意しています：

リアルタイム取引処理の要求
規制遵守
レガシーのメインフレームとの連携
ダウンタイムゼロのアップグレード

政府インフラ

政府システムは、次の理由でXXEリスクが高いです： - 数十年にわたるSOAPベースのシステムの存在 - マルチベンダーの統合要件 - 厳格な認証・認定プロセス - 予算制約による近代化の遅れ - 国家レベルの標的

監視と検知

ロギングとアラート

潜在的なXXE攻撃の兆候を検知するために、詳細なロギングと監視を行います。具体的には：

すべてのXMLパース操作の追跡
信頼できない入力におけるDOCTYPE宣言のアラート
XMLパーサーのファイルシステムアクセスの監視
アプリケーションサーバーからの異常なアウトバウンド通信の検知
複数層にわたるセキュリティイベントの相関

インジケーター・オブ・コンプロマイズ（IOC）

監視すべきポイントは： - SYSTEMやPUBLICキーワードを含むXMLペイロード - cloud metadataエンドポイント（169.254.169.254）へのリクエスト - Webアプリケーションからの機密ファイルアクセス - 大規模なXMLドキュメントや深いネスト構造 - ファイルパスや内部システム情報を示すエラーメッセージ

今後の展望：XXEを超えて

セキュリティ意識と教育

セキュリティはコードを書く前の段階から始まります。開発チームは次のことを行う必要があります：

XXEやその他のインジェクション脆弱性に関する定期的な研修
セキュリティのエバンジェリストの育成
XML処理に特化した安全なコーディングガイドライン
XML処理機能の脅威モデリング

ベンダーのセキュリティ要件

ソフトウェアやサービスの調達時には、次の点を求めるべきです： - XXE対策の実証 - 受け入れ基準にXXEテストを含める - セキュアなXMLパーサー設定の義務付け - 定期的なセキュリティ評価とペネトレーションテスト

結論：”古い”脅威の現代的な影響

XXE脆弱性は、現代サイバーセキュリティにおいて逆説的な存在です。十分に理解され、詳細に記録されているにもかかわらず、2025年でもシステムを脅かし続けています。大手企業やオープンソースプロジェクトに影響を与える最近のCVEは、XXEがいかに重要な脅威であるかを示しています。

XXEの持続は、パーサーのデフォルト設定の不備、複雑なアプリケーションアーキテクチャ、レガシーシステムの制約、そして現代アプリケーションにおけるXML処理の見えない性質に起因します。SOAP APIは、金融、医療、政府などの重要な運用を支えており、そのセキュリティは最優先です。ファイルアップロード機能、特にSVGや他のXMLベースのフォーマットを処理するものは、見落とされがちな攻撃経路です。

解決策は、多層的なアプローチを取ることです：XMLパーサーの堅牢化、堅牢な入力検証、ネットワークのセグメント化、開発パイプラインへのセキュリティテストの組み込み、そしてセキュリティ意識の高い文化の醸成です。XXEを”レガシー”とみなすことはできません。2025年の脅威環境は、それがいかに生きているかを証明しています。

今後も、教訓は明白です：サイバーセキュリティにおいて、「古い」ことは「無関係」を意味しません。基本を怠ると、組織のセキュリティが崩壊する可能性があります。XXEの恐怖は、業界全体が安全なデフォルト設定と包括的な防御戦略にコミットするまで続きます。

キーワード: XML External Entity, XXE脆弱性, SOAP APIセキュリティ, XMLインジェクション, ファイルアップロード脆弱性, XXE防止, Webアプリケーションセキュリティ, サーバーサイドリクエストフォージェリ, XXEエクスプロイト, XMLパーサーセキュリティ, CVE-2025-49493, ブラインドXXE, XXE SSRF, billion laughs攻撃, SVG XXE, SOAPセキュリティ 2025