こんにちは。現場の最前線でセキュリティと向き合っていると、教科書に載っているような「基本の攻撃」ほど、実は一番恐ろしいものだと痛感します。
今日は、Webセキュリティの登竜門であり、今なお多くのサイトを陥れる「反射型XSS（Reflected XSS）」についてお話しします。「XSS？なんか聞いたことあるけど、自分には関係ないかな」と思っているあなたにこそ、ぜひ読んでほしい内容です。
—
1. 反射型XSSって、結局どんな「泥棒」なの？
家で例えてみましょう。あなたの家には「訪問者を受け取る玄関（入力フォームやURLパラメータ）」がありますよね。
反射型XSSは、「偽の宅配業者になりすまして、玄関先で巧妙に仕掛けられた小包を渡してくる泥棒」です。
1. 罠を作る： 攻撃者は、悪意のあるスクリプト（例：あなたのブラウザの情報を盗むコード）を仕込んだURLを作ります。
2. だます： そのURLを、SNSやメールで「これ、見てみて！」とあなたにクリックさせます。
3. 反射（リフレクション）： あなたがクリックすると、そのスクリプトは一度Webサイトに送られ、Webサイトが「検索キーワードはこれですね！」と、そのままあなたのブラウザに送り（反射）返します。
4. 実行： ブラウザは「サイトから送られてきたものだから安心だ」と勘違いし、そのスクリプトを実行してしまいます。
つまり、「サイト側が、攻撃者の言葉をオウム返しして、被害者を攻撃させている」という構図なんです。
—
2. なぜこれが危険なの？
「ただの文字が表示されるだけでしょ？」と思うかもしれませんが、ブラウザ上でスクリプトが動くということは、「あなたのブラウザの権限で、何でもできる」ことを意味します。
- あなたがそのサイトでログイン中なら、代わりに操作（なりすまし）ができる。
- あなたがブラウザに保存している「Cookie（認証情報）」を盗み出すことができる。
これらは、泥棒があなたの家の鍵を複製して、いつでも自由に出入りできるようになるのと同じくらい深刻です。
—
3. どうすれば防げるの？（泥棒を入れないために）
対策の基本は、「玄関で荷物の中身をしっかりチェックすること」です。これをエンジニア用語で「エスケープ処理」や「バリデーション」と呼びます。
対策①：HTMLエスケープ（必須中の必須！）
ブラウザが「これはプログラムだ！」と勘違いしないように、特殊な文字を安全な文字に置き換えます。
<は<に変換する>は>に変換する
こうすることで、ブラウザは「ああ、これはただの文字列なんだな」と理解して、実行せずにただ画面に表示するだけになります。
【コード例：PHPでの実装】
// ユーザーが入力した値を受け取る
$keyword = $_GET['keyword'];
// htmlspecialcharsを使って安全な文字列に変換する
// ENT_QUOTESをつけることで、シングルクォーテーションなども確実に保護します
echo "検索結果: " . htmlspecialchars($keyword, ENT_QUOTES, 'UTF-8');
対策②：HTTPヘッダーで「門番」を強化する
さらに、ブラウザに対して「このサイトはこういうルールで動くから、怪しいスクリプトは無視してね！」と伝える強力な門番がいます。それが「Content-Security-Policy (CSP)」です。
Webサーバーの設定ファイル（ApacheやNginxなど）で、以下のように設定します。
サーバーからの応答ヘッダーにこれを含める
Content-Security-Policy: default-src 'self'; script-src 'self';
（※この設定は「自分自身のドメイン以外から読み込まれるスクリプトは絶対に実行しない！」という強力なガードです）
---
4. 最後に：セキュリティは「疑う」ことから始まる
今日学んだのは、ほんの入口ですが、「ユーザーから受け取ったものを、そのまま画面に出さない」という原則を徹底するだけで、反射型XSSのほとんどは防げます。
開発現場では、「動けばいいや」と急いでしまうことも多いですよね。でも、ちょっとだけ立ち止まって「このデータ、もし悪意のある泥棒が仕掛けたものだったら、どうなるだろう？」と想像してみてください。その「疑う心」こそが、あなた自身と、あなたのサービスを守る最強の武器になります。
まずは、自分の書いているコードで、ユーザーの入力が「そのまま画面に出ていないか」チェックすることから始めてみませんか？一歩ずつ、着実に。それがプロのセキュリティエンジニアへの近道です。
コメント