「とりあえずhtmlspecialchars」で安心するな：文脈依存の出力エンコーディングが守るWebの防波堤
現場のコードレビューをしていると、必ずと言っていいほど目にする光景がある。「とりあえず htmlspecialchars を通しておけばXSS（クロスサイトスクリプティング）は防げる」という呪文のような思い込みだ。
はっきり言おう。その認識は、攻撃者にとっての「招待状」だ。
セキュリティの本質は「どこで、何が、どう扱われるか」の文脈（Context）を読み解くことにある。今日は、インジェクション攻撃の本質と、現場で本当に通用する出力エスケープの極意を叩き込む。
—
1. なぜ「汎用的なエスケープ」が破られるのか？
攻撃者は、ブラウザがデータを「どう解釈するか」というパースの隙を突く。
例えば、HTMLタグの中だけでなく、JavaScriptの変数内、CSSの中、あるいはURLのパラメータとしてデータが埋め込まれる場合、それぞれ必要な「無害化」のルールが全く異なる。
危険なPoC：文脈の不一致が生む悪夢
例えば、JavaScriptの変数にユーザー入力を代入するコードを考えてみよう。
// 攻撃者が name に ‘ ; alert(document.cookie) // を入力した場合
var userName = ‘‘;
htmlspecialchars は &, ", ', <, > をエスケープするが、JavaScriptのコンテキストにおける「改行」や「セミコロン」はそのまま通る。結果、userName の定義が破壊され、攻撃者のスクリプトがブラウザ上で実行される。これが、「文脈依存（Context-aware）のエスケープ」が求められる理由だ。
---
2. 文脈別・防御の鉄則
出力先に応じて、以下の変換ルールを徹底せざるを得ない。
HTML Body内
もっとも基本的だが、タグの属性値（hrefやsrc）に渡す場合は別途対策が必要だ。
- 対策: 信頼できるライブラリ（後述）を使用し、
&,<,>,",'をエスケープする。
JavaScript内（JSONデータ）
ここが最大の盲点だ。JS内で直接文字列を埋め込んではならない。
- 対策: サーバー側で
json_encodeを使い、ブラウザ側ではelement.textContentを利用してDOMを操作する。innerHTMLは原則禁止だ。
CSS/URL内
JavaScriptスキーム（javascript:alert(1)）の挿入が最大の脅威となる。
- 対策: URLの「プロトコル」をホワイトリスト方式でチェックする（
httpかhttpsのみ許可する）。
---
3. 実践：コピペで使えるセキュアな実装コード
モダンなフレームワーク（Laravel, Django, React等）は自動エスケープを備えているが、その「限界」を知っておく必要がある。ここでは、生PHPとJavaScriptでの堅牢な実装例を示す。
PHP: 文脈を意識した出力処理
/
function e($str) {
// ENT_QUOTES | ENT_HTML5 を指定し、シングルクォートも確実にエスケープ
return htmlspecialchars($str, ENT_QUOTES | ENT_HTML5, 'UTF-8');
}
// NG: JavaScriptに直接埋め込むな
// OK: JSONとしてJSに渡し、JS側で安全に扱う
$data = ['name' => $_GET['name']];
?>
Python (Flask/Jinja2): テンプレートエンジンの活用
Jinja2はデフォルトでエスケープしてくれるが、意図的に無効化する | safe フィルタには注意が必要だ。
2
{{ user_input }}
---
4. WAFとIAMで多層防御を固める
コードレベルの対策は「水際」だが、インフラ層での防御は「最後の砦」だ。
- WAF (AWS WAF / Cloud Armor):
XSS や SQLi のシグネチャをブロックするルールを常時有効にせよ。特に、怪しいリクエストパターンを検知したら即座に遮断するのではなく、まずはログ収集・モニタリング（カウントモード）から入るのが運用上安全だ。
- CSP (Content Security Policy):
これが最強の防御だ。HTTPレスポンスヘッダに以下を設定するだけで、インラインスクリプトの実行をブラウザ側で強制的に禁止できる。
# Nginxの設定例
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none';";
---
最後に：プロのエンジニアとしてのマインドセット
セキュリティに「絶対」はない。しかし、「どこにリスクが潜んでいるか」を言語化できるエンジニアは、攻撃者にとって最も厄介な存在だ。
1. 「自動エスケープ」を過信しない。
2. JSへのデータ受け渡しは必ずJSON経由にする。
3. ブラウザの機能（CSP等）を使い、多層的に防御する。
今日からこのルールをチームの標準に組み込んでほしい。泥臭い積み重ねこそが、あなたの作るシステムを、そしてあなたのエンジニアとしての価値を守る唯一の手段だ。
質問があればいつでも来てくれ。コードは嘘をつかないが、書く人間は時として見落としをするものだからな。
コメント