DOM ベース XSS.

DOM ベース XSS(Type-0)は、根本原因がすべてクライアントサイドのコードに存在するクロスサイトスクリプティングの欠陥です。この用語は、2005 年に Amit Klein が論文 "DOM Based Cross Site Scripting or XSS of the Third Kind." で提唱しました。信頼されたソース、すなわち location.hash、location.search、document.referrer、window.name、postMessage、localStorage が、サニタイズされないまま innerHTML、document.write、eval、setTimeout、jQuery.html() といった危険なシンクへ流れ込みます。悪意あるペイロードはしばしば URL のフラグメント(# の後ろ)に乗るため、サーバには一切送信されず、WAF、サーバログ、そして大半の反射型 XSS スキャナーからは不可視となります。

実世界での影響は大きく、DOM XSS は広告や分析タグ、クロスオリジンのデータを信頼する postMessage ハンドラー、そしてレガシーな jQuery セレクター($(location.hash)、1.6.3 より前のバージョンで CVE-2011-4969 として修正)などに繰り返し現れてきました。Google 自身の分析では、同社製品における XSS の大半が DOM ベースであることが判明し、これが Trusted Types の開発の動機となりました。対策としては、textContent や setAttribute のような無害なシンクを優先し、DOMPurify や組み込みの Sanitizer API でサニタイズし、Trusted Types と厳格な Content Security Policy を強制し、コードレビュー時にソースからシンクへのフローを追跡する汚染解析(taint-tracking)ツールを実行することが挙げられます。

flowchart LR
  A["ソース<br/>location.hash / postMessage"] --> B[クライアントサイド JS<br/>が値を読み取り]
  B --> C{サニタイズ済み?}
  C -->|"textContent / DOMPurify"| D[安全に描画]
  C -->|"生文字列を innerHTML,<br/>eval, document.write へ"| E[シンクがペイロードを実行]
  E --> F[攻撃者のスクリプトが<br/>被害者のセッションで実行]
  F --> G[Cookie 窃取、アカウント<br/>乗っ取り、キーロギング]
  E -.->|Trusted Types が阻止| H[TypeError、実行なし]