XSS・CSRF・SQLi — データとコードの境界が壊れる

What — 3つに共通する形

一見まったく違う3つの脆弱性ですが、データとして扱うべきものが、命令として解釈されるという同じ構造を持っています。

// 入力
検索キーワード: <script>steal()</script>

// 出力される HTML
<p>"<script>steal()</script>" の検索結果</p>
     ~~~~~~~~~~~~~~~~~~~~~~~~
     ブラウザはこれを「データ」ではなく
     「実行すべきスクリプト」と解釈する

XSS の被害範囲

Why — なぜ「エスケープ漏れ」が繰り返されるのか

3つの脆弱性がなくならない理由は、安全な書き方より危険な書き方のほうが短くて自然だからです。

// 危険だが、自然に書ける
const sql = `SELECT * FROM users WHERE id = ${id}`;
element.innerHTML = `<p>${keyword}</p>`;

// 安全だが、一手間かかる
db.query('SELECT * FROM users WHERE id = ?', [id]);
element.textContent = keyword;

人間が毎回正しく選ぶことに期待する設計は、必ずどこかで破れます。だから現代のフレームワークは、既定を安全側にする方向に進みました。

• React・Vue は、変数を埋め込むと自動でエスケープする。危険な書き方には dangerouslySetInnerHTML のようなわざと長くて怖い名前が付いている
• ORM やクエリビルダは、既定でプレースホルダを使う
• 主要なフレームワークは、CSRF トークンを既定で有効にする

安全な道が既定で、危険な道に進むには明示的な操作が要る。 この形をとることで、うっかりミスが構造的に減ります。

CSRF はなぜ成立するのか

CSRF が成立する条件は2つだけです。

1. ブラウザが Cookie を自動で送る（同一オリジンポリシーは「送信」を止めない）
2. サーバーがリクエストを「本人の意図」だと信じる

CSRF トークンは、2番目を壊します。攻撃者のページはあなたのページの中身を読めないので、フォームに埋め込まれたランダムなトークンを知りようがありません。

<form method="POST" action="/transfer">
  <input type="hidden" name="_csrf" value="ランダム値">
  ...
</form>

サーバーはこのトークンがセッションのものと一致するかを確認します。攻撃者は正しい値を書けないので、リクエストは弾かれます。

「読めないこと」を利用して「本人性」を作る——同一オリジンポリシーの上に立った、簡潔な仕組みです。

演習 — まず自分で判断する

解説を読む前に、まず自分で判断してみてください。ここで一度詰まっておくと、 次の節の判断軸が「なるほど」ではなく「そう来たか」に変わります。