ベニー・チャーニーの著書『Cybersecurity Upside Down』について詳しく知る

詳しくはこちらから
サイト翻訳には人工知能を利用しており、正確性を追求しておりますが、必ずしも100%正確とは限りません。ご了承ください。

誰も注目していないファイル転送:業界標準のXMLが新たなXXE攻撃の標的になりつつある理由

著者: ジョセフ・グエン、プロダクトマーケティングマネージャー
この記事を共有する

2026年1月、OPSWAT は Apache Tikaの重大な脆弱性であるCVE-2025-66516に関する分析を公開しました。 悪意のあるPDFがバックエンドのパーサーに到達することで引き起こされるものです。修正策は簡潔でした。ファイルがパーサーに到達する前にサニタイズを行い、パーサーがペイロードを一切見ないようにするのです。これが機能したのは、パーサーが1つ、ファイル形式が1つ、そして既知のライブラリが1つしかなかったからです。

では、そのXMLがPDFではなく、SSO(シングルサインオン)プラットフォームにインポートされる設定ファイル、財務自動化エンジンに送信されるワークフロー定義、あるいは病院の統合システムで処理される医療データだった場合はどうでしょうか? こうしたファイルは、組織、委託業者、規制当局、パートナーの間を毎日行き来しており、管理されたファイル転送やパートナーポータルを通じて、信頼できるビジネス入力データとして届きます。しかし、ほとんどのデータサニタイゼーションソリューションは、これらのファイルを検査することさえありません。

XMLは産業界の共通言語であり、そこが問題なのだ

PDFおよびSVGのXXE(XML外部エンティティ)攻撃は、同じ手口で発生します。ユーザーがファイルをアップロードし、バックエンドのライブラリがそれを解析し、パーサーがペイロードを実行するという流れです。侵入経路は明らかです。

業界向けのXMLは事情が異なります。これらは、既知のパートナー、規制当局、請負業者、ベンダー間で行われるB2Bデータ転送、設定情報のインポート、およびシステム間でのデータ転送です。その一見正当に見える性質こそが、ウェブ上のアップロードに適用される厳格な審査をすり抜ける理由となっているのです。

XMLは、数多くの業界の業務運営に深く浸透しています:

  • 金融サービス:SWIFTメッセージ、FIX(Financial Information eXchange)の指示、およびISO 20022に基づく支払いは、いずれもXML形式です。
  • 医療:医療データ交換の標準プロトコルであるHL7(Health Level Seven)およびFHIR(Fast Healthcare Interoperability Resources)は、XMLを基盤としています。FHIRのペイロードに含まれる悪意のあるエンティティは、構造はチェックするもののDOCTYPEはチェックしないシステムをすべて通過してしまいます。
  • エンタープライズIT:ID管理およびSSOプラットフォームは、統合、移行、およびオンボーディングの際にXML設定ファイルを取り込みます。1回のインポートで、そのプラットフォームが認証を行うすべてのアプリケーションに反映させることができます。
  • OT:SCADAおよびエネルギー管理システムは、IEC 61968および61970で定義されたXML形式でデータを交換しており、多くの場合、制御が最小限に留まるIT/OTの境界を越えて行われる。

いずれの場合も、ペイロードはスクリプトやマクロではなく、XMLのコンテンツ層に存在します。具体的には、ローカルファイルのパスまたは内部エンドポイントを指す外部エンティティを参照するDOCTYPE宣言です。パーサーがこのファイルを処理する際、そのコンテンツを取得します。

このファイルはスキーマチェックの観点からは構造的に有効ですが、その内容については、例えばDOCTYPEで宣言されている内容やエンティティが指す先など、より詳細な検証が必要です。

これは過去の遺産による問題ではない

XXEは2003年に報告され、2017年にOWASP Top 10に追加されたため、チームによってはこれがすでに解決済みであると見なしてしまうことがあります。しかし、2025年および2026年の記録はそうではないことを示しており、ファイルのセキュリティにおいて重要なのは、ペイロードがファイルとして届くケースです。

  • lxml (CVE-2026-41066):広く使用されているPythonのXMLライブラリにおけるデフォルトのパーサー設定により、信頼できないXMLによってローカルファイルが読み込まれる可能性がありました。lxmlは、svglibがSVG(Scalable Vector Graphics)ファイルの解析に使用するのと同じライブラリであり、svglibは2024年のSVG XXEに関するブログ記事で、ファイル経由のパス「OPSWAT 」を用いてこの脆弱性を実証しました。ファイルをサニタイズすることで、パーサーがそれを認識する前にエンティティを削除することができます。
  • Atlassian Crowd (CVE-2026-21569, CVSS 7.9 高):SSOおよびID管理プラットフォーム。細工されたXMLペイロードにより、攻撃者はローカルまたはリモートのファイルへのアクセス権を取得する。また、CVSSの「Scope:Changed」評価は、エクスプロイトが成功した場合、Crowdが認証を行うすべてのアプリケーションに影響が及ぶことを意味する。このXMLは、パートナーまたは管理者のワークステーションからの設定ファイルや統合用インポートファイルとして送信される。
  • IBM Business Automation Workflow (CVE-2025-13096, CVSS 7.1 High):IBM BAWは、融資の組成や保険金請求処理などのワークフローにおいてXMLを処理します。この脆弱性により、ファイルの漏洩やSSRF(Server-Side Request Forgery)が発生し、攻撃者が内部エンドポイントへアクセスできるようになります。また、同じDOCTYPE構造がDoS(Denial of Service)を引き起こすエンティティ展開を引き起こす可能性があります。 このXMLは、保険査定人、規制当局、インテグレーターからパートナーポータルを通じて送信されます。

これらはすべて、ある共通の形態を指し示しています。それは、DOCTYPEペイロードを含む信頼されたビジネス用XMLファイルであり、脆弱性のあるパーサーに到達する前に、確立されたワークフローを通じて送られてくるものです。

範囲に関する注記:この ブログでは、 ファイルとして届くXXEについて論じています。XML、およびSVG、XFAを含むPDF、OfficeファイルなどのXMLベースの形式は、サニタイズ処理ワークフローを経由することで、安全な状態に再構築されます。 ファイル経由のケースは、アップロード、設定のインポート、パートナーとのデータ交換、メールの添付ファイルなど、一般的なものです。生のAPI リクエスト本文やコード内のパーシング呼び出しを通じて発生するXXEには、転送中のファイルが存在しないため、その経路にはファイルサニタイズゲートウェイは存在しません。

Deep CDR™ テクノロジーによるスタンドアロン XML ファイルの処理方法

Deep CDR™ テクノロジーは、XML 1.0 および 1.1 に加え、ZEI、JNLP、TDS、RDF、BML、MPD、TTML などの関連する XML ベースのフォーマットを、同一のエンジン上でサポートしています。

XMLファイルの場合、ドキュメントの外部を指す参照はデフォルトで拒否され、DOCTYPEおよびその外部エンティティ参照は再構築されたファイルには反映されません。これらの動作はいずれも、個別に特定して調整する必要があるポリシーではありません。外部のXMLがMetaDefender Core™のサニタイズワークフローを経由する限り、この保護機能は適用されます。

XXE (DTD) はデフォルトでサニタイズされます

このデフォルトのDOCTYPE削除機能に加え、オペレーターは自身の環境に合わせて設定できる追加の制御機能を利用できます

MetaDefender Core XML設定を表示するXML設定パネル
  • マクロの削除:XMLベースのOffice形式にエンコードされたVBAマクロを削除します
  • CDATAの削除:「何もしない」から「すべて削除」までの4段階のポリシーオプションがあり、ワークフローの機密性に応じて、チームがCDATAセクションの処理の厳格さを制御できるようになっています。
  • インジェクションの除去:XMLインジェクションおよび要素の値に埋め込まれたコンテンツ層のJavaScriptに対処します
  • Base64エンコードされたデータの処理:XML値に埋め込まれたエンコード済みペイロード(データURLスキーマのパターンを含む)を処理します
CDATAの削除例
XMLインジェクションはデフォルトで無効になっています

これに関連する保護機能は、同じ方向の反対側もカバーしています。メモリを使い果たすまで拡張するように記述された構造体は検出され、削除されるため、小さなファイルが処理の過程で巨大なファイルになることはありません。こうした理由から、この現象は「XMLボム」(または「Billion Laughs」)と呼ばれています。

XMLボムの除去例

すべてのサニタイズ処理は、フォレンジック用JSONレポートに記録されます。このレポートには、オブジェクト名、削除されたコンテンツ(1エントリあたり5,000文字まで)、および削除されたオブジェクトのSHA-256ハッシュが含まれます。セキュリティチームは、元のファイルを再調査することなく、コンプライアンス審査やインシデントの再現に必要な完全な監査証跡を利用できます。

XMLインジェクション、CDATAインジェクション、XMLボム、および関連するXML攻撃の手法に関する詳細な説明については、当社の XMLドキュメントの攻撃ベクトルに関する技術的な詳細解説をご参照ください。

XMLファイルのワークフローを保護する

信頼できるパーサーが悪意のあるXMLファイルに遭遇した場合、そのファイルが勝ってしまう。Apache Tika、Atlassian Crowd、IBM BAW、そしてSVGのパーシングパスは、ドキュメントパイプライン、IDプラットフォーム、ワークフローエンジンといったさまざまな場面において、この事実を裏付けている。

これらのファイルは脅威とは見なされません。これらは、確立されたワークフローを通じて既知のパートナーから送信され、正当なコンテンツを含んでいるため、効果を発揮するのです。対策はCVEごとに変わるものではありません。転送層で傍受し、ファイルがパーサーに到達する前にクリーンアップを行い、保護の対象を電子メールの添付ファイルやWebへのアップロードだけでなく、外部のXMLデータファイルにも確実に拡大させる必要があります。

タグ

OPSWATで最新情報をお届けします!

今すぐご登録ください、 ストーリー、イベント情報などをお届けします。