SVGサニタイズの七年戦争：Scratchの教訓

Apr 27, 2026 · coding security · Source ↗

まとめ

Scratchが七年にわたってSVGサニタイズの穴を塞ぎ続けてきた歴史は、攻撃者が制御するSVGをライブDOMに直接パースする設計が構造的に危険であることを示している。

根本原因：Scratchはバウンディングボックスを計算するために、ユーザー投稿のSVGをメインドキュメントに直接追加する。この設計がある限り、どんなサニタイズ手法も本質的に脆弱になる。
2019〜2026年のCVE連鎖：scriptタグ、大文字小文字を区別しないregexバイパス、<image href>によるHTTPリーク、CSSの@import、Paper.js経由のXSS、url()リーク、image-set()リーク――修正のたびに新たな迂回経路が生まれてきた。
DOMPurifyの立場：DOMPurifyはHTTPリークのブロックを明示的にスコープ外としており、「確実なブロックは実現不可能」と明言している。Scratchは新たなCSSベクターが出るたびにカスタムフックを追加で実装するしかなかった。
未修正の2026年バグ：長いCSSトランジションを使った任意のページスタイル書き換えが可能で、フィッシング用オーバーレイや報告ボタンの非表示化が実際のscratch.mit.edu上で可能な状態のまま残っている。
未修正のimage-set()HTTPリーク：2025年にScratchへ報告された脆弱性で、6ヶ月の猶予期間が過ぎた後に本記事で開示された。

コメント欄ではホワイトリスト方式が現実的な代替案として収束した。実用的なSVGの大半はパスとフィルだけで構成されており、「悪用されやすい危険な機能」だけをブロックすれば、延々とパッチを当て続けるサイクルから抜け出せるという意見が多数を占めた。
Google Slidesの事例が具体的な業界証拠として取り上げられた。SVGインポート機能への要望は約15年前から存在するにもかかわらず未実装のままであり、大規模チームがサニタイズ問題を検討した末に断念したことを強く示唆している。
TinyVGが安全な代替フォーマットとして提案されたが、アニメーション未対応とエコシステムの未成熟が普及の障壁として指摘された。

@spankalee：Google Slidesは約15年来の機能リクエストがあってもSVGサポートを実装していない。サニタイズはスケールでは解決不可能と見なされているという強い状況証拠。
@ikkun：TinyVGをより安全なベクターフォーマットとして支持しつつも、アニメーション非対応を実際の欠点として指摘。