「あなたのサイト、誰でも自由に書き換えられるとしたら？」反射型XSSの正体と対策
こんにちは。セキュリティの世界で長いこと「デジタルな泥棒」たちと追いかけっこをしてきた経験から、今日は「反射型XSS（クロスサイト・スクリプティング）」という、ウェブ開発の現場で最も身近でありながら、最も見くびられがちな攻撃についてお話しします。
「XSS？ 名前は聞いたことあるけど、自分たちのサイトは大丈夫でしょ」と思っていませんか？ 多くのエンジニアがその油断で、顧客の個人情報を盗まれる悪夢を見てきました。一緒に、家の防犯に例えて紐解いていきましょう。
—
1. 反射型XSSは「偽の招待状」を送りつける手口
まず、反射型XSSを「家の防犯」でイメージしてみましょう。
あなたは家主（Webサーバー）です。玄関先で「こんにちは、〇〇さん！」と訪問者の名前を呼んで歓迎するシステム（検索結果画面など）を作ったとします。
ここで悪い泥棒（攻撃者）は、こんな「偽の招待状（URLパラメータ）」を誰かに送ります。
https://example.com/search?name=
普通の人は自分の名前を入力するところに、泥棒は「悪意のあるプログラム（スクリプト）」を忍ばせました。あなたが何も考えずにこのURLを訪問者に踏ませると、サーバーは何も疑わずに画面にこう表示します。
「こんにちは、 さん！」
ここが最大の盲点です。 ブラウザは、その文字列が「名前」なのか「命令」なのかを判断できません。「あ、これは実行しろっていう命令なんだな」と勘違いして、その場でスクリプトを動かしてしまいます。これが「反射型」のメカニズムです。泥棒が投げたボール（入力）が、そのまま跳ね返って（反射して）持ち主を攻撃するわけです。
—
2. なぜ「入力値の検証」だけでは足りないのか？
「じゃあ、変な文字を入力させないようにすればいいんでしょ？」と思うかもしれません。もちろん、それは正しいです（これを「入力バリデーション」と言います）。
しかし、泥棒はあらゆる抜け道を探します。全角・半角の混在、エンコードの書き換え、あるいはバリデーションのわずかな隙間……。「入力だけを信用する」のは、鍵を一つしかかけないのと同じで、非常に危険です。
セキュリティの鉄則は「多層防御」です。入力の入り口だけでなく、画面に文字を表示する「出口」でも対策を行う必要があります。
—
3. 今すぐできる「出口」の対策：出力エンコード
ブラウザに「これはスクリプトじゃなくて、ただの文字だよ」と教えてあげる方法があります。これが「出力エンコード」です。
例えば、< という記号を、ブラウザが命令と勘違いしないように < という別の表現に変換します。
- 変換前:
コメント