普通、外部から受け取るデータは「ただのデータ」であって、サーバーに何かを命令する力は持たないはずです。しかしXMLのエンティティ機能は、データの中に「この外部リソースを読み込んで埋め込め」という小さな命令を紛れ込ませることを許します。攻撃者はこの仕組みを使い、本来は外部に見せないはずのサーバー内部のファイル（設定ファイル、認証情報、ソースコードなど）を、XMLの応答の中に埋め込ませて読み出します。データのつもりで受け取ったものが、実は命令を含んでいた——これが信頼境界の崩れ方です。

XXEは新しい攻撃ではなく、XMLが広く使われ始めた頃から知られている古典的な脆弱性クラスです。それでも今なお、XMLを扱うあらゆる場面（設定ファイル、ドキュメント形式、SOAP API、SAML認証など）で繰り返し報告され続けています。次のセクションでは、その鍵となる「エンティティ」の仕組みを見ていきます。

XMLのエンティティは、文書の冒頭にある<!DOCTYPE>（DTD＝文書型定義）の中で宣言します。一番身近なのは「内部エンティティ」で、これは単なる文字列の置き換えです。たとえば<!ENTITY item "ノート">と宣言しておくと、本文中の&item;がすべて「ノート」に置き換わります。これだけなら便利な略語機能にすぎません。問題は次の「外部エンティティ」です。

XXEの厄介なところは、攻撃が「XMLの仕様どおりの正しい動作」として起きる点です。古くからあるXMLパーサーの多くは、外部エンティティの解決を標準で有効にしていました。つまり開発者が何も特別なことをしなくても、パーサーが「親切に」ファイルを読みに行ってしまうのです。アプリ側のコードには「ファイルを読む」という処理が一行も書かれていないのに、XMLライブラリの内部でファイルが読まれてしまうため、コードレビューでも見落とされがちです。

次の実践チャレンジでは、この「親切すぎるパーサー」を安全に再現した環境で、XMLインポート機能を通じてサーバー内部のファイルを読み出す流れを体験します。なお、このシミュレーターは実際のファイルには一切アクセスせず、あらかじめ用意した架空のファイル一覧の中だけで動作します。

架空のToDoアプリ「ToDoループ」には、設定をXMLでインポートする機能があります。下のインポート欄に入力したXMLは、外部エンティティの解決が有効な（＝脆弱な）パーサーで処理されます。最初は内部エンティティの例が入っています。これを外部エンティティ（SYSTEM "file://..."）に書き換えて、サーバー内部のファイルを読み出してください。このサーバーには、次のファイルが存在することがわかっています。

• 外部エンティティ・DTDを無効にする：XMLパーサーの設定で、外部エンティティの解決とDTDの処理そのものを禁止する。これがXXE対策の本丸で、多くのライブラリには専用の設定がある
• そもそもDTDを許可しない：信頼できない入力に対しては、DTD（<!DOCTYPE>）を含むXMLを丸ごと拒否するのが最も確実
• 可能ならXMLをやめてJSONを使う：JSONにはエンティティのような外部リソース読み込みの仕組みがないため、XXEの心配がない。新規設計では検討する価値がある
• ライブラリを安全な既定値のものに保つ：近年のXMLライブラリは外部エンティティを既定で無効にしているものが増えている。古いライブラリやレガシー設定に注意する
• WAFは補助に留める：<!ENTITYなどのパターンを検知するWAFは入口を狭めるが、エンコーディングや変種で回避されうるため、根本対策はあくまでパーサー設定

外部から受け取ったものを、どこまでの権限で処理するか——XXEもまた、第2話のSSRFや第7話のOAuthと同じ「信頼境界」の物語です。次のセクションで今回の学びをまとめます。

第8話では、XMLの外部エンティティ機能を悪用して、サーバー内部のファイルを読み出すXXEを体験しました。CTFの「フラグ探し」ではなく、XMLを扱うあらゆる場面で今なお報告され続けている、息の長い脆弱性クラスそのものです。