脆弱性の見出しを読んでも、XMLインジェクションがスポットライトを浴びることはほとんどない。RCEやSQLiのようなパンチの効いた知名度もなく、派手なリモートエクスプロイトのように視覚的にドラマチックでもない。しかし、SOAPエンドポイント、レガシーXML API、ドキュメント処理パイプライン、SAML/SOAP統合など、多くの企業スタックにおいて、XMLインジェクションは信頼された入力をロジックのミスに変える静かな失敗モードである。
XMLインジェクションは単一の悪用ではありません。攻撃者が制御するXMLが、サーバーがリクエストをどのように解釈するかを変更する一連の動作を指します。つまり、XPathクエリが突然予期しないレコードを返したり、パーサが意図しない外部リソースを解決したり、エンティティの拡張がCPUとメモリを消費したりします。攻撃者から見れば、これらはファイルを読んだり、内部リクエストをトリガーしたり、有用な混乱を引き起こしたりする、実用的な構成要素です。守備側から見れば、同じ部品はロジックと観測可能性のギャップを修正するためのナビゲーションマップです。
ささやかで具体的な味わい - プレーブックは誰にも渡さない
このパターンを見るのに、派手なペイロードは必要ない。素朴な文字列連結によってリクエストフィールドからXPathを構築するサーバーサイドのコードを想像してみてください：
// 脆弱なパターン（擬似）
userId = request.xml.user.id
role = request.xml.user.role
query = "doc('/db/users.xml')/users/user[id = " + userId + " and role = '" + role + "']"
result = xmlEngine.evaluate(query)
これは、もし ユーザーID そして 役割 は整形式である。しかし、ユーザー入力にクエリの構造を制御させると、クエリ間の境界が曖昧になります。 データ そして ロジック.XPathインジェクションは当然の帰結である。脆いクエリを操作して真理条件を変更し、本来返すべきでない行を返すことができる。
もう1つの軸は、エンティティやDTDの処理である。多くのXMLエンジンは、文書型宣言、エンティティ、外部参照を許可している。正規のコンポジションには便利だが、信頼できない入力に対してオンにすると危険である。防御ルールは単純で、エンティティの展開やDOCTYPE処理が必要ない場合は、オフにすることだ。
難解なエクスプロイトよりもコンフィギュレーションの解析が重要な理由
この問題には2つのレベルがある。1つ目はビジネスロジックのバグで、信頼できない値をクエリロジックに渡したり、XMLをXPathやXPathライクな評価器にテンプレート化したり、"整形式 "が "安全 "を意味すると思い込んだりすることだ。これはデザインによって修正可能だ。検証し、正規化し、データとクエリを分離する。
つ目は、パーサーの動作である。XMLパーサーは強力で、ファイルの内容をフェッチしたり、HTTPリクエストを行ったり、入れ子になったエンティティを展開してメモリを膨張させたりすることができる。これらの機能は、制御されたコンテキストでは問題ないが、パブリックな入力を受け入れると悲惨なことになる。従って、現実的な防御はパーサーのハードニングとビヘイビアテレメトリーである。
実践的で技術者に優しい対策（例付き）
安全のためにXMLを禁止する必要はない。3つの習慣的な変更が必要だ：
1) パーサーの能力を制限する。 ほとんどの言語では、外部エンティティやDOCTYPE処理を無効にすることができる。例えば、Javaでは（擬似API）：
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance()；
dbf.setFeature("", true)；
dbf.setFeature("", false)；
dbf.setFeature("", false)；
またはPythonで defusedxml (デフォルトで安全な動作をするライブラリを使用する）：
from defusedxml.ElementTree import fromstring
tree = fromstring(untrusted_xml)
2) 検証し、正規化する。 エンドポイントに必要なタグが少ない場合は、XSD を検証するか、予期しない DOCTYPE を拒否する。文字列の連結によってクエリを構築するよりも、データ構造へのパースやパラメータ化されたアクセスを優先しましょう。
3) 計器と警報。 DOCTYPE/ENTITYを参照するパーサー例外、パーシングサービスからの突然のDNS/HTTP送信、パーシング中に開始されたファイルオープン操作など、奇妙なシグナルを監視するフックを追加する。これらのシグナルは、静的なルールリストよりもはるかに実用的です。
ディフェンダーを実際に助ける検出可能な信号
モニタリングのチューニングを行う際には、脆弱なテキストシグネチャではなく、実際の挙動を確認すること：
- パーサー・プロセスから発信されるアウトバウンドDNSまたはHTTPコール。
- XMLの処理中にローカルパスへのファイルアクセス試行が発生する。
- DOCTYPE または外部エンティティ解決に関するパーサー例外のトレース。
- 突然内部のみのフィールドやデータを含むレスポンス（XPathやクエリ操作を示す）。
- 通常負荷時の解析コードにおいて、CPU/メモリが異常なスパイクを起こす。
そのようなことに注意を促し、迅速にトリアージすることができる。
無謀にならない練習方法
検出ルールの検証、パーサハードニングの動作確認、CTFスタイルのトレーニングなど、実験を行いたい場合は、管理されたラボでのみ行ってください。本番環境に不正なXMLを持ち込まないこと。代わりに、隔離されたVM、証明可能なラボの範囲、またはXMLを生成するツールを使用してください。 衛生的、非搾取的 テストケース
自然言語ワークフロー - Penligentのループ内
そこで、実用的な自動化が威力を発揮する。パーサーの設定や検出ロジックを検証するためだけに、何十ものテストを手作業でコーディングする必要はない。以下のような自然言語駆動のペンテストツールを使えば、テストは自動化されます。 寡黙その流れは、日常的な言葉ではこうなる：
「XML インジェクションのリスクがないか、ステージング SOAP エンドポイントをチェックしてください。安全なプローブのみを使用し、パーサの例外、ファイルアクセスイベント、および送信 DNS/HTTP コールバックを収集する。優先順位をつけたハードニング手順を作成する。
Penligentはこの文章を、お客様の許可されたテスト環境に対する、的を絞ったサニタイズされたチェックに変えます。Penligentは、（ライブのエクスプロイトチェーンではなく）焦点を絞ったテストケースを実行し、遠隔測定（パーサーエラー、ファイルアクセスログ、DNSコールバック）を収集し、証拠を関連付け、簡潔な修正チェックリストを返します。CTFプレイヤーにとっての利点はスピードです。シェルスクリプトを書いたり、何十ものペイロードファイルを作成したりすることなく、仮説を検証し、検出が成功したかどうかを知ることができます。
閉会の辞
XMLインジェクションは、脆弱性リーダーボード上では地味に見えるが、その真の威力はステルス性にある。XMLインジェクションは、データレイヤーが無害であること、パーサーが "期待通り "に動作すること、モニタリングが明らかな障害を検出すること、といった仮定を悪用する。パーサーの特権を最小化し、データとロジックを分離し、積極的に検証し、重要なシグナルを計測する。自然言語のインテントを安全なバリデーション実行に変換するツールは、面倒な作業を取り除き、チームが修正と学習に集中できるようにする。
Japanese 
English 
German 
French 
Spanish 
Portuguese 
Korean 
Hindi 
Arabic 
Turkish 
Hebrew