その「便利機能」が泥棒を招く？XSS（クロスサイトスクリプティング）を家防犯で理解しよう
こんにちは。セキュリティの世界へようこそ。
システム開発をしていると、「ユーザーが入力した名前を画面にそのまま表示する」なんてことは日常茶飯事ですよね。でも、実はその何気ない処理が、あなたのシステムに「泥棒のマスターキー」を渡してしまう可能性があるとしたらどうでしょう？
今日は、Webセキュリティの登竜門であり、今なお最も恐ろしい攻撃の一つ「XSS（クロスサイトスクリプティング）」について、身近な防犯に例えてお話しします。
—
1. XSSって何？：家に例えるなら「勝手に合鍵を作られる」こと
XSSとは、悪意のある攻撃者が、Webサイトに「偽のスクリプト（命令）」を紛れ込ませる攻撃のことです。
これを家に例えてみましょう。あなたの家（Webサイト）には、郵便受け（入力フォーム）がありますよね。通常、郵便受けには手紙が入るはずですが、もし誰かが「勝手に家の中に入って、冷蔵庫のプリンを盗み食いし、さらに合鍵を作って玄関の鍵を開けておく」ような指示書を郵便受けに放り込んだらどうでしょう？
Webの世界では、この「指示書」が「悪意のあるJavaScriptコード」であり、ユーザーのブラウザという「家の中」で、攻撃者のコードが勝手に実行されてしまうのがXSSの恐怖です。
—
2. なぜ「そのまま表示」がいけないの？
例えば、ユーザーの名前を表示するだけのシンプルなコードを想像してください。
もし攻撃者が名前に と入力したらどうなるでしょうか。ブラウザは「ああ、これは画面に表示する文字だな」ではなく、「おっ、プログラムの命令だな。実行しよう！」と勘違いしてしまいます。これがXSSのメカニズムです。
—
3. 鉄壁の守り：コンテキストに応じた「出力エンコーディング」
では、どう守ればいいのでしょうか？ 答えは「出力エンコーディング」です。これは、郵便受けから入ってきた怪しい指示書を、「これは実行命令ではなく、ただの紙切れ（文字）ですよ」と書き換えてしまう作業です。
実は、場所（コンテキスト）によって、書き換えのルールが少し違います。
① HTMLタグの中（普通の文章として出す場合）
の中に表示するなら、特殊な記号を「文字実体参照」という形に変換します。
<→<>→>&→&
これをしておけば、ブラウザは < を見ても「タグの始まりだ！」と思わず、「ただの『<』という記号が表示されているんだな」と正しく認識してくれます。
② HTML属性の中（ など）
ここはさらに警戒が必要です。"（ダブルクォーテーション）で囲まれた中であれば、" を入力されると属性を閉じられてしまい、別の命令を埋め込まれます。
"→"'→'
③ JavaScriptの中に直接埋め込む場合
これは最も危険です。文字列として扱うにしても、\（バックスラッシュ）などでエスケープしないと、いくらでも悪さをされます。極力、JavaScriptの中にサーバーサイドの変数を直接書くのは避けましょう。 どうしても必要な場合は、JSONエンコードを通すのが鉄則です。
---
4. 実装のヒント：自分で書くより「ライブラリ」を信じよう
自分で毎回「この記号はこれに変換して…」と考えるのはミスのもとです。最近のモダンなフレームワーク（React, Vue, Angularなど）は、デフォルトでこの出力エンコーディングを自動的に行ってくれます。
もしPHPなどで直接書くなら、以下のように準備しましょう。
// 安全な出力のための関数例
function h($string) {
// ENT_QUOTES: シングルクォートとダブルクォートの両方を変換
// UTF-8: 文字コードの指定
return htmlspecialchars($string, ENT_QUOTES, 'UTF-8');
}
// 使うときは必ずこの関数を通す！
echo "
";
---
5. 最後に：セキュリティは「疑う」ことから始まる
防犯と同じで、Webセキュリティに「完璧な一度の対策」はありません。
- 入力値は決して信用しない（性悪説）
- 出力する直前で、その場所に合わせたエスケープを行う
この二つを徹底するだけで、あなたのサイトの安全性は劇的に向上します。「面倒だな」と思うかもしれませんが、それがあなたのユーザーと、あなた自身のシステムを守る唯一の鍵です。
今日からコードを書くとき、「このデータ、そのまま画面に投げても大丈夫かな？」と、ほんの少しだけ立ち止まって考えてみてください。その「疑う癖」こそが、世界最高峰のエンジニアへの第一歩ですよ！
コメント