【ITニュース解説】“Day 28: The DOM Clobbering Coup — How I Turned a Simple Comment Box into a CSP Bypass”

Webサイトの安全性は、現代のインターネット社会において非常に重要な要素だ。日々、新しい技術が生まれる一方で、それらを悪用しようとする攻撃者も常に存在し、Webサイトの脆弱性を狙っている。今回の事例は、「DOM Clobbering」という少し特殊な手法を使って、Webサイトのセキュリティを守るための仕組みである「Content Security Policy（CSP）」を突破し、悪意のあるコードを実行したというものだ。システムエンジニアを目指すなら、このような攻撃の仕組みと、それに対する防御策を理解することは必須となる。

まず、Webページがどのように動いているのか、その基本的な部分から見ていこう。私たちがブラウザで見ているWebページは、HTMLという言語で書かれている。HTMLは、ページの構造や内容を決めるもので、「見出し」「段落」「画像」といった要素を定義する。これらのHTML要素は、ブラウザがページを表示する際に「Document Object Model（DOM）」という形でメモリ上に表現される。DOMは、HTML文書をオブジェクトの集合体として扱うための仕組みで、プログラムからHTMLの構造や内容を自由に変更できるようにする窓口のようなものだ。そして、JavaScriptというプログラミング言語は、このDOMを操作することで、ページの見た目を動的に変えたり、ユーザーの操作に応じてさまざまな処理を実行したりする役割を担っている。例えば、ボタンをクリックすると画像が変わるといった動きは、JavaScriptがDOMを操作している結果だ。

次に、今回の攻撃の核心である「DOM Clobbering」について説明する。これは、ブラウザが持つ少し特殊な、あるいは歴史的な互換性のために残っている特性を悪用する攻撃手法だ。Webブラウザは、古いWebページでも正しく表示できるように、過去の仕様の一部を現在も引き継いでいることがある。その一つに、「HTML要素の特定の属性（特にid属性やname属性）が、JavaScriptのグローバル変数としてアクセスできてしまう場合がある」という特性がある。通常、JavaScriptで変数を使う場合は明示的に宣言するが、DOM Clobberingは、攻撃者がWebページに特定のidやnameを持つHTML要素を挿入することで、既存のJavaScriptコードが期待しているグローバル変数やオブジェクトを、意図しない形で「上書き（clobber）」してしまう攻撃だ。例えば、Webページに<input id="myVar" value="悪意のある値">というHTML要素が挿入されたとする。もし、このページで元々myVarというグローバル変数を使っているJavaScriptがあった場合、そのmyVarはHTMLInputElementオブジェクトに上書きされてしまい、元々の変数が持っていた値や機能が失われる。これがDOM Clobberingの基本的な考え方だ。

そして、この攻撃が突破しようとしたのが「Content Security Policy（CSP）」というセキュリティ機構だ。CSPは、Webサイトのセキュリティを強化するための重要な盾として機能する。Webサイトには、クロスサイトスクリプティング（XSS）のような攻撃からユーザーを守る必要がある。XSS攻撃では、攻撃者が悪意のあるJavaScriptコードをWebページに埋め込み、それをユーザーのブラウザで実行させようとする。CSPは、HTTPヘッダーを通じてブラウザに「このサイトでは、どのサーバーからスクリプトを読み込んで良いか」「インラインのJavaScriptは実行して良いか」といった厳格なルールを指示することで、このような悪意のあるコードの実行をブロックしようとする。Webサイト運営者は、信頼できるリソースのURLだけを許可するようにCSPを設定することで、もし万が一XSS脆弱性があったとしても、攻撃コードが実行されるのを大幅に防ぐことができる。

今回の攻撃事例は、コメントボックスという、ユーザーが自由にテキストを入力できる機能が悪用されたものだ。通常のコメントボックスであれば、投稿された内容はただのテキストとして表示されるか、HTMLタグも使えるとしても、危険なJavaScriptは無効化されるはずだ。そして、今回のサイトではCSPも導入されており、直接的なJavaScriptの埋め込みはブロックされていた。しかし、攻撃者はDOM Clobberingという手法に目をつけた。攻撃者は、コメントボックスに、悪意のあるスクリプトを直接書くのではなく、特定のidやname属性を持つ巧妙なHTML要素を投稿したのだ。

例えば、Webサイトの既存のJavaScriptコードが、_というグローバルオブジェクトの中に、サイトの設定を格納したconfigというプロパティがあると仮定しよう。つまり、JavaScriptコードは_.configといった形で設定値にアクセスする。攻撃者は、コメントボックスを通じて<form id="_" name="_"><input id="config" name="config" value="悪意のあるコードを実行する文字列"></form>のようなHTMLを挿入した。このHTMLがWebページにレンダリングされると、DOM Clobberingの特性により、JavaScriptのグローバル変数_は、もはや元の設定オブジェクトではなく、攻撃者が挿入した<form>要素そのものに上書きされてしまう。さらに、_.configにアクセスしようとすると、それは<form>要素の子要素である<input id="config">に上書きされる。結果として、元のJavaScriptコードが_.configから設定値を取得しようとした際、攻撃者が<input>要素のvalue属性に仕込んだ文字列（例えば、JavaScriptのeval()関数を使って任意コードを実行させるような命令）を「正規の設定値」として読み込んでしまうことになったのだ。

このようにして、Webサイトの正規のJavaScriptコードは、攻撃者が仕込んだ値を使って、意図しない動作をさせられてしまう。CSPは、どのスクリプトファイルを読み込むかを制限したり、インラインスクリプトの実行を禁止したりするが、この攻撃は「正規のJavaScriptコードの内部ロジック」を歪めることで、その正規のコード自身が悪意のある動作をするように仕向ける。これにより、CSPが「正当なスクリプト」と判断していたコードが悪質な振る舞いをすることになり、結果的にCSPの防御網をすり抜けて、攻撃者の目的であるJavaScriptの実行が達成されたというわけだ。

この事例から学べることは多い。Webサイトのセキュリティは、単に危険なコードをブロックするだけでは不十分で、ブラウザの持つ特性や、正規のコードの動作原理までも理解し、攻撃者がどこを狙ってくるかを予測する必要があるということだ。システムエンジニアを目指す皆さんは、コードを書くだけでなく、Webセキュリティに関する知識を常にアップデートし、このような巧妙な攻撃手法にも対応できるスキルを身につけることが求められるだろう。Webセキュリティは常に変化し続ける分野であり、今回の事例のように、一見すると無害に見える機能やブラウザの古い特性が、予期せぬ形で悪用される可能性も常に潜んでいるのだ。