XMLドキュメントが「整形式」として検証されていないか、スキーマに対してチェックされていない場合、リスクは何ですか？
アプリケーションでXMLドキュメントを処理する場合、どのようなリスクがありますか？例えば。 「整形式」でない場合、またはスキーマに対してチェックされていない場合。
「整形式」のXMLドキュメントがある場合でも、攻撃を防ぐことはできません。インジェクションによってXMLドキュメントが常に壊れるわけではありません。 XMLインジェクション攻撃を防ぐには、次の対策が役立ちます。
- 有効なXMLスキーマ定義を確認してください。
- 入力を検証/サニタイズします。
- エンコーディングをチェックして強制します。
答えを完全にするために、いくつかの便利なリンクを追加したいと思います。
DTDとXSDを使用した安全なXML処理はトリッキーです。
パーサーでxmlファイルを処理する前に、ユースケースで正しいdtdとxsdが参照されていることを確認する必要があります（代替xmlns、xml内のローカルdtd定義、エンティティ展開などの混合xmlコンテンツは追加されません）。
OWASPポッドキャストで聞いたように OWASPポッドキャストはこちらからダウンロード であり、このコンテキストで特に関連があります。受け入れたデータ（xmlコンテンツ）をホワイトリストに登録し、そのコンテンツに関する既知の問題をブラックリストに登録しないでください。
外部参照をオフにするのはすばらしいことです（誰かが/ etc/passwdまたは/ etc/shadowファイルを、dtdの代わりにfile：//プロトコルを使用して参照することで読んだと考えてください）。
リゾルバとカタログファイルを使用して、外部参照を制御/置き換えることができますが、破壊できない既知の適切なローカルコピー http://xml.Apache.org/commons/components/resolver/resolver-article.html
Sun/Oracleによるマルチスキーマバリデーターなどの外部検証プログラム/ライブラリーを使用できます。 http://msv.Java.net/ これは、内部的に検証するものが何もない場合でも検証を提供し、RELAXなどの異なる/補完的なテクノロジーを使用できますNG = xmlを検証します。
あらゆる種類のインジェクション（SQL、Javascript、xmlns、image、svg、url、xslt、xpathなど）に注意してください。これらはすべてインジェクトされて、アクティブ化し、dbサーバーの危険となるコンテキストに送信される可能性があるためです。アプリサーバーまたはクライアント環境。 IE妥協案を含むbase64でエンコードされた画像で、インフラストラクチャ内のWebページに送信される（ゲームオーバー））を考えてみましょう。
Xml処理インフラストラクチャでのサービス拒否も心配になる可能性がありますが、システムに関連しない場合があります。
注：@anonymousは、関連リソースにいくつかの素晴らしいURLを提供しています。
XMLを構文チェックしない主なリスクは、無効な解析です。
XMLを読み取るソフトウェアが無効な入力を処理できない場合は、クラッシュしたり、予期しない何かが起こったり、自然に爆発したりする可能性があります（おそらくそうではありません）。これらの状況は、セキュリティ上の欠陥につながる可能性があります。ただし、ソフトウェアが脆弱で、無効なXMLを処理すると、「有効な」データでさえ、他のセキュリティ上の欠陥が発生する可能性が高くなります。
類推として、ほとんどのWebアプリのセキュリティホール（SQLインジェクションなど）は無効なHTMLでは攻撃されませんが、構文的に有効な入力は解析時に問題を引き起こします。あなたの場合、XMLが入力です。特にXSD/DTD /何かが自動生成された場合は特に、スキーマチェックだけでは入力を検証するのに十分ではありません。アプリケーション自体で入力を処理するものはすべて、それもチェックする必要があります。