目次
XMLを読み取り、必要な値だけをDBへ保存する。このような処理でも、解析器が文書内の外部参照を解決すると、サーバーのファイルやネットワークへアクセスする入口になる場合があります。解析は単なる文字列の読み取りとは限りません。
本記事は2026年10月18日にOWASPの一次資料を確認した実務解説です。特定製品の新しい脆弱性の速報ではありません。連携データを取り込む構成は仮想例で、点検の順序と検証方法は本サイトの提案です。XMLを使うこと自体が危険なのではなく、文書にどこまで処理の自由を与えるかを確認します。
スポンサーリンク
XMLがどの機能から入るかを一覧にする
連携API、業務ファイルの取り込み、古いSOAPサービス、署名を含む文書など、XMLの入口を調べます。画面にXMLという名前がなくても、ライブラリや変換ツールの内部でXMLを扱う場合があります。ファイルの拡張子だけで対象外と判断しないことが重要です。
本サイトは、入力元、受け付ける形式、最初の解析器、スキーマ検証、後続の変換、保存先を一列に記録することを勧めます。一つの処理で安全な設定を使っていても、後段が別の解析器へ同じ文書を渡すなら、そちらの設定も確認します。
社内システムから届くデータも、信頼する範囲を明確にします。送信元の侵害、連携先の設定ミス、再送ファイルの差し替えを想定し、文書の内容がサーバーの任意の資源を選べる構造にしないようにします。
出典：OWASP XML External Entity Prevention Cheat Sheet。
DTDと外部実体参照の役割を理解する
XMLには、DTDや実体参照など文書の解釈に関わる仕組みがあります。外部実体を解決する設定では、解析器が文書外の資源へアクセスする場合があります。XXE対策では、この参照を必要以上に許さないことが中心になります。
OWASPは、可能ならDTDを無効にし、外部実体などを扱わない設定を選ぶ方法を説明しています。ただし、設定名や既定の挙動は言語、ライブラリ、版によって異なります。別の解析器向けのコードをそのまま貼り付けて完了としないでください。
DTDの処理を止めること、DOCTYPEを含む文書を拒否すること、外部へのアクセスを止めることが、すべて同じ設定で実現するとは限りません。業務として何を許し、何を拒否したいかを定め、その条件へ対応する設定を実機で確認します。
スポンサーリンク
外部参照を許す必要がある場合は解決先を限定する
既存の連携仕様にDTDやスキーマへの参照が含まれる場合、直ちにすべてを拒否すると業務が止まる可能性があります。その場合は必要な資源を管理下で固定し、任意の外部URLやファイルを選べない解決方法を検討します。
本サイトの提案は、業務で必要な識別子と管理下の既知の資源を対応付ける方法です。未知の参照は安全に失敗させ、参照の解決に失敗したときだけ外部へ取りに行くような例外を残さないことが重要です。
外部への通信を制限することは補助になりますが、ローカルファイルの参照まで同じ意味で防ぐわけではありません。解析器の機能制限、実行環境の権限、ネットワークの制御を別々に扱い、どの層が何を止めるかを記録します。
スキーマ検証とXIncludeも別の段階として見る
文書の型を検証する処理が安全であっても、その前に外部参照が解決されれば、入力の形を確認するだけでは防ぎ切れません。スキーマを使っているからXXEは起きないという判断を避けます。スキーマそのものをどこから取得するかも確認します。
XIncludeやXSLTなど、XMLに関わる別の機能を使う場合は、その機能が参照する資源の扱いを確認します。最初のパーサーに設定した外部参照の制限が、後段のすべての処理へ自動的に引き継がれると考えないでください。
保守されているライブラリへ更新することも基本です。ただし、既定では安全な版でも、互換性のために追加したオプションが外部参照を再び有効にしている場合があります。バージョンと、有効な設定の両方を追えるようにします。
スポンサーリンク
外部参照の停止と資源消費の制限を分ける
ネットワークへの参照ができなくても、文書内の展開や深い構造、大きな入力によって資源を消費する可能性があります。XXEの外部参照対策と、解析のサービス妨害対策を一項目で済ませないことが重要です。
本サイトは、受信するバイト数、展開後の量、要素や属性の数、深さ、処理時間、同時実行数を用途に沿って制限する方法を提案します。利用する解析器が提供する上限と、アプリ側で制御する上限を対応させます。
過大な入力を拒否したときは、解析済みの一部だけが保存されていないかを確認します。業務として部分取り込みを許す場合も、その条件と結果を明示します。エラーが起きたので処理は何もしていないはずだと推測しないようにします。
解析環境のファイルと資格情報を減らす
専用のワーカーへ解析を分ける場合、必要な入力と出力だけが見える構成にします。Webアプリの本番設定や、他利用者のファイルを解析処理へ一緒に渡す必要があるかを確認してください。
外部通信が不要なら、通信しない環境を検討します。必要な通信がある場合は、解析する文書が自由に宛先を選べないようにします。環境の分離は、パーサーの設定不備や未知の問題の影響を広げないための補助です。
一時ファイルは成功時だけでなく、解析失敗、時間切れ、ワーカー停止でも回収できるようにします。例外の内容を利用者へ返すときに、内部のパスや接続情報がそのまま出ないことも確かめます。
隔離環境で外部アクセスを観測する
自分が管理する検証環境に、架空データと観測用の無害な参照先を用意します。通常のXMLが正しく取り込まれることを確認した後、許可していない参照を含む入力を処理し、ファイルや通信へのアクセスが起きないことを観測します。
解析エラーの有無だけで合格にしません。アプリがエラーを表示する前に通信している場合や、ログへファイル内容を出している場合を見落とさないためです。観測には実際の秘密ファイルや第三者のシステムを使わないでください。
正常なスキーマ、未知の参照、必要な設定が欠けた状態、上限を超えた入力を別々に試します。設定が無効だと起動時に分かる方式なら、その失敗を無視せず検知できることも確認します。
| 対象 | 確認する条件 | 期待する結果 |
|---|---|---|
| 通常のXML | 必要な業務データを含む | 定めた項目だけを取り込む |
| 未知の外部参照 | 管理下にない参照先を含む | 通信やファイル参照を行わない |
| 大きな構造 | 量や深さが上限を超える | 安全に中断し部分状態を残さない |
| 後続の変換 | 別の解析器を経由する | 各段階で制限が維持される |
古い連携を残すときに例外を狭くする
古い取引先との連携だけ外部参照が必要な場合、すべてのXML処理へ緩い設定を広げないようにします。対象となる入口、参照する資源、実行環境、担当者、例外を解消する条件を記録します。
文書内の文字列から機械的にDOCTYPEを削除するような独自の前処理は、解析器の制御を置き換えるものにはしません。入力を安全なものへ変えたつもりで、別の解釈や必要な署名の不整合を生む可能性があるためです。
形式をJSONなどへ移せる場合も、業務要件と移行の影響を確認します。形式を変えただけで、認可、入力の量、後続処理の安全性が解決するわけではありません。不要な機能を減らし、残る境界を明示することが大切です。
スポンサーリンク
固定したスキーマを使う連携の確認例
仮想の受発注連携で、決められたスキーマだけが必要だとします。その場合、入力文書が指す任意の場所から毎回スキーマを取る必要があるかを検討します。管理下で版を固定した資源と、許可した識別子を対応付ける方が、通信と仕様変更を追いやすくなります。
固定した資源も更新管理の対象です。取引先の仕様が変わったときに、誰が内容を確認して入れ替えるか、古い文書をどの版で処理するかを決めます。未知の版を受け取ったからと、解析器の制限を全面的に解除する例外を足さないでください。
試験では、正規の識別子に対応する文書が通ることに加え、存在しない識別子、許可していない参照先、必要なローカル資源が欠けた条件を確認します。失敗時の案内と、運用者が取る手順まで用意すれば、エラーが出たときに安易な設定緩和へ進みにくくなります。
解析器を共通関数へまとめる場合も、後段の変換がその関数を経由しているかを調べます。共通設定を作った事実だけでは、古い独自の解析経路へ保護が届いたことにはなりません。実際に通る呼び出しと、ライブラリ更新後の動作を確認します。
仕様変更とライブラリ更新を再確認の契機にする
新しいXML項目、署名の検証、別の変換ツールを追加するときは、解析経路を再確認します。元のパーサーだけを点検した記録を、機能が増えた後もそのまま適用しないでください。
運用の記録には、解析器と版、必要な機能、外部参照の方針、処理量の上限、試験した範囲を残します。失敗した文書の全文を無差別に保存するより、機密性を守りながら原因を再現できる専用のサンプルを作る方が扱いやすくなります。
XML対策の基準は、設定名を一つ覚えることではありません。入力から変換、保存までの各段階が、どの外部資源へ届き、どの量まで処理し、失敗したとき何が残るかを説明して検証できる状態を維持することです。
スポンサーリンク
参考資料
以下は2026年10月18日に直接確認した一次資料です。製品やサービスの設定は、実際に利用する版と環境に対応する資料で確認してください。
