2026.05.01 2026.05.14

【XXE編】XMLに混ざる悪意の参照とファイル漏洩の経路｜CTF思考フレームワーク #17

安全に生きたい編集部

📖 この記事はシリーズの一部です

「CTF思考フレームワーク」　Web脆弱性編　#17 / 公開中 10記事　→　シリーズ一覧を見る →

注意：この記事で扱う内容は、必ずCTF・自分の検証環境・許可された診断範囲でのみ確認してください。実在するWebサービス、API、SSO基盤、社内XML処理に対して無断で試すことは、不正アクセスや業務妨害につながる恐れがあります。

XXE（XML外部実体参照）は、XML処理を行うサーバで、攻撃者が「外部実体」を仕込んでファイル読み取り・SSRF・DoSに持ち込む攻撃。SOAP API、SAML認証、SVGアップロード、Officeファイル（docx/xlsx）処理などXMLが裏に潜む箇所が標的になります📄

XMLは「ただのデータ形式」と侮りがち。でも仕様には「外部のファイルを取り込む」機能が標準で入ってます。

難易度：★★★（上級）

XML仕様を悪用するXXEは、ファイル漏洩からSSRFまで一気に行ける危険な脆弱性です📜

XXEはXML外部実体参照の機能を悪用してサーバ内部のファイルを読む攻撃だよ📜

Contents

👀 観察フェーズ：まず何を見る？
🤔 仮説フェーズ：攻撃者は何を考える？
🔬 検証フェーズ：どうやって確かめる？
⚔️ 攻撃フェーズ：CTFで見る典型パターン
🛡️ 防御フェーズ：どう守る？
🔑 あわせて見直したい基本対策
⚠️ よくある落とし穴
🧰 ツール早見表
🎓 本気で学びたい人へ
📚 もっと深く学びたい人へ
📚 次に読みたい
🧪 自分で検証してみる
⚖️ 大事なお約束

👀 観察フェーズ：まず何を見る？

まずアプリがXMLを受け取る箇所を探す！SOAP、SAML、RSS取込、SVG、DOCX/XLSXなどが盲点🔍

JSONが主流の今でもXMLは生き残っています。特に企業向け・認証系・ドキュメント処理に多いので要チェック。

SVG画像アップ・DOCX解析・SOAP API・SAML SSOはXXEの宝庫。<?xml>を含むリクエストはすべて疑います👀

画像にしか見えないSVGでもXML実体参照がそのまま動いちゃうんだね…😨

🤔 仮説フェーズ：攻撃者は何を考える？

XXEの典型は4経路。

📁 仮説①：ローカルファイル読込

外部実体宣言にローカルファイルパスを指定し、サーバ上のシステムファイルや設定ファイルを読み出させるパターン。パーサが外部実体を解決するとレスポンスにファイル内容が反映されることがあります。

🌐 仮説②：SSRF経由で内部ネット

外部実体宣言にURLを指定し、サーバ自身から内部ネットワーク・クラウドメタデータ・社内APIへ到達させるパターン。外部に公開されていない資源が射程に入る恐れがあります。

🤐 仮説③：Blind型(OOB)

レスポンスに結果が出ない場合でも、外部DTDやパラメータ実体参照の扱いによって、外部通信の有無からパーサの挙動を推測されることがあります。

💥 仮説④：Billion Laughs(DoS)

入れ子になった実体参照でメモリを指数的に消費させてサービス停止。

XXEは「XMLパーサの設定1つ」が運命を分ける脆弱性。デフォルトが安全な言語と危険な言語があります。

XMLって地味なのに攻撃面が広すぎるんだね…💧

🔬 検証フェーズ：どうやって確かめる？

CTFやローカル検証環境で、DOCTYPE宣言と外部実体参照を含むXMLを送り、レスポンスやエラーに外部リソースの内容が反映されるかを確認！実サービスへは絶対に投げない🧪

レスポンスに何も出なくても、外部通信の有無からパーサの挙動が分かるんだね🧪

⚔️ 攻撃フェーズ：CTFで見る典型パターン

XXEで起こりうる問題はこの3つ。

ここでは実サービスに対して試せる手順ではなく、CTFやローカル検証環境でよく出る「考え方」だけを整理します。具体的な検証は、必ず自分の環境・CTF問題・許可されたラボ内で行ってください。

① 機密ファイル漏洩

OSのシステムファイルや、アプリケーションの設定ファイル・環境変数ファイルなどが読み出される恐れがあり、認証情報やAPIキーが漏洩するパターン。

② クラウドメタデータへの到達リスク

XXE経由でクラウドのメタデータサービスへ到達されると、インスタンスに付与されたロール情報など、通常は外部から見えない情報へアクセスされる恐れがあります。権限設定が広すぎる場合、重要データへの横展開リスクになります。

③ Blind XXEによる外部通信リスク

レスポンスに結果が出ないアプリでも、XMLパーサが外部リソースへアクセスできる場合、外部通信の発生自体が情報漏えいや内部構成の推測につながる恐れがあります。

CTF{disable_external_entity_in_xml_parser}

結論はシンプル：「外部実体参照を無効化する」。これだけでXXEの大半は防げます。

🛡️ 防御フェーズ：どう守る？

XXE対策の3点セット！🛡️

🚫 外部実体・外部DTDを無効化

パーサーの外部実体参照とDOCTYPE宣言の処理を無効化します。Javaならdisallow-doctype-declとexternal-general-entities、.NETならXmlResolverをnullに、Pythonならdefusedxmlを使うのが基本（OWASP XXE Prevention Cheat Sheet準拠）。

📦 安全なライブラリ・新バージョンを使う

Java/.NET/PythonなどのXMLパーサーは最新版へ。デフォルト設定が安全な実装(defusedxml等)を採用。

🔍 入力の事前チェック

パーサ側の設定が確実に効いていることを優先しつつ、<!DOCTYPEや<!ENTITYを含むペイロードを前段で検知して拒否するレイヤーも置きます。ただし、文字列検知だけを主防御にせず、必ずXMLパーサ側で外部実体・外部DTDを無効化します。

XMLパーサの安全設定は、言語やバージョンごとに違うから、デフォルトを信じすぎないのが大事なんだね💪

🔑 あわせて見直したい基本対策

XXEの直接対策ではありませんが、セキュリティ全体を見直す際に、パスワードの使い回しも同時に改善しておくと安心です。パスワード管理ツールを使って、サービスごとに異なるパスワードを管理しましょう。

※ 上記は他社サービスへのリンクです。購入は各自でご判断ください。

⚠️ よくある落とし穴

ライブラリのデフォルト設定を信用して、実は外部実体が有効なまま。
PHPのlibxmlを古いバージョンで使い続け、disable_entity_loader未設定。
Java DocumentBuilderFactoryで FEATURE_SECURE_PROCESSING のみ有効化し、disallow-doctype-declを設定し忘れる。
docxの中身をunzipせずに丸ごとXMLパーサに食わせる。
SAMLライブラリを使う際、署名検証とXXE対策を別々に管理して片方だけ有効。
Out-of-band XXEを「ネットワーク的にegress制限あるから大丈夫」と過信。

🧰 ツール早見表

ツール・資料	用途	ひと言
defusedxml (Python)	安全なXML処理	外部実体の解決をデフォルトで防ぐ防御ライブラリ
OWASP XXE Prevention Cheat Sheet	防御設計	主要言語のパーサ別の安全設定が網羅されている
各パーサの公式ドキュメント	設定確認	言語/バージョンごとに安全な初期化方法が異なる
SAST / 静的解析ツール	コードレビュー	XMLパーサの危険な初期化パターンを検出
egress制御・ログ監視	OOB対策	Out-of-band XXEの兆候を検知・遮断