「誰かの悪意が、あなたのサイトの『備品』になる」――蓄積型XSSの恐怖と防衛術
こんにちは。セキュリティの最前線で、日々泥臭いインシデントと格闘しているエンジニアです。
今日は、初心者エンジニアの皆さんが必ず一度は耳にする「XSS（クロスサイト・スクリプティング）」、その中でも特にたちが悪い「蓄積型（ストアド）XSS」について、専門用語を並べる前に、身近な「家の防犯」に例えてお話ししましょう。
1. 蓄積型XSSって、つまりどういうこと？
想像してみてください。あなたは自分の家の玄関先に「伝言板」を置きました。誰でも自由に書き込める、便利な掲示板です。
ある日、泥棒がやってきて、その伝言板に「この家の合い鍵を、こっそり作成する機械」の設計図を書いていきました。通りがかった家族や友人がその伝言板を見るたびに、その設計図が自動的に読み込まれ、気がつかないうちに被害者のスマホから大切なデータが泥棒に送信されてしまう……。
これが「蓄積型XSS」のメカニズムです。
- 「掲示板」＝あなたのWebサイトのデータベース
- 「設計図」＝悪意あるJavaScriptコード
- 「通りがかった人」＝あなたのサイトを閲覧するユーザー
反射型XSSが「通りすがりの悪戯」だとすれば、蓄積型は「サイトの備品に毒を仕込む」ようなもの。一度汚染されると、サイトを訪れる全員が被害に遭うという非常に恐ろしい事態になります。
—
2. なぜ「保存する時」が一番大事なの？
多くの初心者が陥る罠が、「表示する時に気をつければいいんでしょ？」という考えです。もちろん表示時の対策も大事ですが、それでは「すでに毒が入った水」を飲み続けるようなもの。
一番の防御は、「毒を中に入れないこと」です。つまり、データベースに保存する前の「バリデーション（入力チェック）」が命綱になります。
悪い例（これでは泥棒を招き入れています！）
// バリデーションなしでそのまま保存！
$comment = $_POST[‘comment’];
$db->execute(“INSERT INTO comments (body) VALUES (‘$comment’)”);
これだと、ユーザーが と入力しただけで、そのままDBに保存されてしまいます。
—
3. 具体的な「防衛の鍵」をかけよう
では、どうすればいいのでしょうか？ 一歩ずつ対策を学んでいきましょう。
対策その1：エスケープ処理（無害化）
ブラウザが「これはただの文字ですよ」と認識するように、特殊な記号を別の文字に変換します。
<→<>→>
これだけで、ブラウザは「ああ、これはプログラムではなく、ただの文字だな」と判断して実行しなくなります。
対策その2：出力時のエンコード
現代の開発フレームワーク（LaravelやRails, Reactなど）は、デフォルトでこのエスケープ処理を自動で行ってくれるものが多いです。しかし、「生（Raw）で出力する」という特別な命令を使うと、セキュリティの鍵が外れてしまいます。「フレームワークの標準機能」を信じて、余計なことはしないのが一番の安全策です。
---
4. 最後の砦：HTTPレスポンスヘッダー「CSP」
コードの書き方だけでなく、サイト全体を守る「防犯カメラと警備員」のような仕組みもあります。それがCSP（Content Security Policy）という設定です。
サーバーからブラウザに、「このサイトでは、外部から読み込むスクリプトは許可しない！」という命令を送ることで、万が一悪意あるコードが埋め込まれても、ブラウザが実行を拒否してくれます。
設定例（Webサーバーの設定に追加）:
外部のスクリプト読み込みを禁止し、インラインスクリプトも実行させない最強の防壁
Header set Content-Security-Policy "default-src 'self'; script-src 'self';"
---
最後に：あなたを守る一番の武器は「疑うこと」
セキュリティ対策は、一度やって終わりではありません。新しい機能を作るたびに、「もしここに悪意あるコードを入力したらどうなる？」と一度立ち止まって考えてみてください。
- 入力されたデータは、すべて「毒」かもしれないと疑う。
- 「出力」する場所では、必ず「無害化」を徹底する。
- フレームワークの「自動エスケープ」を過信せず、仕様を理解する。
泥棒は、鍵のかかっていない窓を探して歩いています。皆さんが書くコード一つひとつが、ユーザーの大切な情報を守る「頑丈な鍵」になることを願っています。
さあ、次はどんな機能を実装しましょうか？ 安全なコードを書いて、自信を持って世界に公開していきましょう！
コメント