【テクニカル・上級編】SVG画像ファイルに埋め込まれたXSSの脅威と検証手法 – アプリケーションセキュリティ & 安全な開発防御ガイド

SVGという「トロイの木馬」:アプリケーションの境界を無力化するXSSの深淵

多くのエンジニアが「画像アップロード機能」を安直に捉えている。MIMEタイプをチェックし、拡張子を制限すれば安全だという認識は、残念ながら数年前の遺物だ。特にSVG(Scalable Vector Graphics)は、画像という皮を被った「実行可能なXMLドキュメント」であり、現代のWebアプリケーションにおける最大の盲点の一つと言える。

本稿では、SVGがなぜXSSの温床となるのか、その低レイヤの挙動と、現場で通用する防衛アーキテクチャについて、チーフホワイトハッカーの視点から解剖する。

—

1. なぜSVGは「画像」であって「画像ではない」のか

SVGはXMLベースのベクタ画像フォーマットであり、ブラウザはこれを単なるピクセルデータの集合体ではなく、DOMの一部として解釈する。つまり、SVGファイルの中に記述されたスクリプトは、ブラウザの実行コンテキスト(Origin)でそのまま実行される。

攻撃者が仕掛けるのは、典型的には以下のようなコードだ。




さらに巧妙なケースでは、 のように、静的なタグの属性にイベントハンドラを埋め込む。これはDOM型XSSの変種であり、静的な解析ツール(SAST)をすり抜けることが多い。

—

2. 脆弱性の根本原因:暗黙の信頼とContent-Typeの罠

多くの開発現場では、Content-Type: image/svg+xml が付与されているから安全だ、あるいはアップロード時にライブラリでバリデーションしているから大丈夫だ、と高を括っている。しかし、ここには以下のプロトコル的な落とし穴がある。

1. MIME Sniffing: ブラウザが Content-Type を無視し、ファイルの中身を精査して勝手に実行形式と判断する挙動。X-Content-Type-Options: nosniff が設定されていない限り、攻撃は成立する。
2. DOMの汚染: アップロードされたSVGを タグの src 属性として読み込む場合、ブラウザは「画像」として処理するため、スクリプトは実行されない。しかし、 や