Vue.jsの v-html という「パンドラの箱」：DOMベースXSSの深淵とアーキテクチャによる防御
フロントエンド開発において、v-html は強力なツールだ。しかし、セキュリティの現場で数々のインシデントを追ってきた者から言わせれば、このディレクティブは「利便性という名の甘美な罠」に過ぎない。
多くのエンジニアは「サニタイズすれば大丈夫」と安易に考える。だが、そのサニタイズ処理が、ブラウザのHTMLパーサーの挙動やDOMの構築ロジックと乖離していたとき、攻撃者はその隙間に滑り込んでくる。今日は、v-html を巡るXSS（クロスサイトスクリプティング）の根本的なリスクと、アーキテクトが備えるべき多層防御について語ろう。
—
1. なぜ v-html が「メモリの脆弱性」に直結するのか
v-html の背後にあるのは、ブラウザの innerHTML プロパティの直接的な呼び出しだ。これは単に文字列をレンダリングするのではなく、ブラウザのレンダリングエンジンに対して、パース済みのマークアップをDOMツリーに注入するよう命令する。
攻撃者の視点で見れば、これは「パーサーに対するプロトコル・インジェクション」だ。
例えば、DOMPurify を使わず、あるいは不完全な正規表現だけでフィルタリングした場合、攻撃者は SVG や MathML 名前空間を悪用した、パーサーの解釈差異を突くペイロードを送り込む。これらはブラウザのメモリ上でDOMノードとして生成される際、特定のプロパティ（onload や onerror）が実行される。結果として、JavaScriptコンテキストが乗っ取られ、ブラウザのCookieや localStorage に保持されたセッションデータが、攻撃者のC2サーバーへパケットとして叩き出される。
2. 「サニタイズ」という概念の再定義
単に「スクリプトタグを消す」というブラックリスト方式は、現代のブラウザでは通用しない。攻撃者は javascript:alert(1) のような古典的な攻撃は使わない。彼らは、HTMLエンティティの二重符号化や、制御文字（Null Byteなど）を駆使して、パーサーが「安全」と判断する境界線を揺さぶり続ける。
防衛戦略において最も重要なのは、「信頼できない入力値には決して v-html を当てない」という原則だ。もしどうしても動的なHTMLレンダリングが必要なら、以下のアーキテクチャを実装しなければならない。
実践的な防衛コード（DOMPurifyを用いた構成）
import DOMPurify from ‘dompurify’;
// セキュリティアーキテクトとしての推奨設定
// 不要な要素や属性を徹底的にホワイトリストで弾く
const cleanHTML = (dirty) => {
return DOMPurify.sanitize(dirty, {
ALLOWED_TAGS: [‘b’, ‘i’, ‘em’, ‘strong’, ‘a’], // 必要なタグのみに限定
ALLOWED_ATTR: [‘href’, ‘title’], // インラインイベントハンドラ(on)は絶対許可しない
USE_PROFILES: { html: true },
RETURN_DOM_FRAGMENT: false,
RETURN_DOM: false
});
};
// Vueコンポーネントでの使用例
// 計算プロパティを通して安全な状態のみをテンプレートに流し込む
computed: {
safeContent() {
return cleanHTML(this.userInput);
}
}
3. 生成AI時代の新たな脅威：プロンプト・インジェクションとの融合
現在のフロントエンドセキュリティで最も警戒すべきは、LLM（大規模言語モデル）の出力結果を v-html で直接レンダリングすることだ。
AIは「安全だ」と判断したコードであっても、プロンプト・インジェクションによって悪意のあるHTMLを生成させることが可能だ。AIが生成した回答をそのままフロントエンドに流し込むことは、「AIモデルの入力を信頼してDOMを生成する」という、極めて危険な行為である。
この場合、単なるHTMLサニタイズでは不十分だ。以下のガードレイルが必要となる。
1. Content Security Policy (CSP) の厳格化:
v-html を使用せざるを得ない場合でも、script-src 'self'; を徹底し、インラインスクリプトの実行を物理的に遮断せよ。たとえ v-html で onerror が注入されても、CSPが実行をブロックする。
2. サンドボックス化:
もしAIの出力内容を制御できないのであれば、iframeの sandbox 属性を活用し、スクリプト実行を許可しない隔離環境でレンダリングする。
4. まとめ：防衛の要諦
技術の進化とともに、攻撃のレイヤーも「コードの脆弱性」から「アーキテクチャの仕様」へとシフトしている。v-html を使う際、あなたは単なる開発者ではなく、ブラウザという強力な実行環境の門番であるという自覚を持つべきだ。
- 原則:
v-htmlは常に「悪意があるもの」として扱う。 - 防御:
DOMPurifyを使用し、且つ厳格なCSPを適用する。 - 思想: 「入力の検証」ではなく「出力の分離」こそが、サイバーセキュリティの真髄である。
次世代のアプリケーションを構築する際、あなたが書いたその v-html が、数年後の脆弱性診断で致命的な「Critical」として指摘されないことを願う。守るべきは、画面上の表現ではなく、ユーザーの信頼とデータそのものなのだから。
コメント