泥棒はなぜ「鍵の隙間」を見逃さないのか？SQLインジェクションを紐解く
こんにちは！セキュリティの世界へようこそ。今日は、Webアプリ開発の現場で最も恐れられ、かつ最も身近な「SQLインジェクション」という攻撃について、一緒に深掘りしていきましょう。
難しい専門用語が並ぶと頭が痛くなりますよね。でも大丈夫。「家の防犯」に例えれば、その仕組みは驚くほどシンプルに見えてくるはずです。
1. SQLインジェクションって何？「合鍵」を作られる恐怖
まずはイメージしてください。あなたのWebサイトを「一軒の家」だとします。そして、ユーザーがIDやパスワードを入力する検索窓やログインフォームは「玄関の鍵穴」です。
本来、鍵穴には「正しい鍵（正しいID）」しか入りません。しかし、もしあなたが鍵穴の形をちゃんと管理していなかったらどうなるでしょう？ 泥棒は、針金のような「悪意のある命令（SQL文）」を鍵穴に突っ込み、無理やりドアを開けてしまいます。これがSQLインジェクションです。
データベースという金庫の中身を、泥棒が勝手に覗いたり、最悪の場合は空っぽにしたりする。これがこの攻撃の正体です。
2. 「ブラインドSQLi」という静かな忍び足
次に、少し高度な「ブラインドSQLi」についてお話しします。
普通の泥棒はドアを壊して堂々と入りますが、頭の良い泥棒は違います。彼はドアを壊す代わりに、「ノックして、反応があるかどうか」を繰り返すのです。
- 「そこにデータはあるか？ あるなら1秒だけ応答を遅らせろ（時間差攻撃）」
- 「この文字は正しいか？ 正しいならエラーを表示しろ（エラーベース攻撃）」
泥棒は、画面に何も表示されなくても、応答の速さや微妙な挙動の変化だけで、金庫の中身を少しずつ、まるでパズルのピースを埋めるように盗み出します。画面上では何も起きていないように見えるからこそ、気づいた時には全て盗まれている……これがこの攻撃の恐ろしいところです。
3. 実践：やってはいけないコードと、守るべきコード
では、現場でどう対策すればいいのか。まずは「やらかしてしまう」コードを見てみましょう。
// 危険な例：ユーザーの入力をそのままSQLに組み込んでいる
$id = $_GET['id'];
$sql = "SELECT * FROM users WHERE id = " . $id;
// もしここで $id に "1 OR 1=1" なんて入れられたら、全データが丸裸です！これでは、玄関のドアに「誰でも開けられます」と書いているようなものです。では、どう守るべきか？ 答えは「プリペアドステートメント（準備された文）」を使うことです。
// 安全な例：値を「命令」と切り離して処理する
$stmt = $pdo->prepare('SELECT * FROM users WHERE id = :id');
// 変数を直接埋め込まず、あとから安全に流し込む
$stmt->execute(['id' => $_GET['id']]);
$user = $stmt->fetch();これを使えば、泥棒がどんなに怪しい呪文（SQLコマンド）を入力しても、データベースはそれを「ただの文字列」として扱うため、悪さはできません。鍵穴にどんな形の針金を入れても、鍵として認識されないようにガードを固めるイメージですね。
4. 現場で役立つ「守りのヘッダー」たち
開発の現場では、コードの修正に加えて、ブラウザに「うちのサイトは堅いよ！」と伝える仕組みも重要です。HTTPヘッダーに設定を加えるだけで、攻撃の成功率をグッと下げることができます。
例えば、Content-Security-Policy ヘッダーなどを適切に設定することで、万が一入力値に悪意あるスクリプトが含まれていても、ブラウザ側で「怪しい動きは実行させない！」とブロックさせることが可能です。
最後に：セキュリティは「完璧」より「継続」
「自分は大丈夫」と思っている時ほど、隙が生まれるものです。でも、最初から完璧を目指す必要はありません。
1. 入力を信じない（ユーザーが入力するものは全て疑う）
2. 命令とデータを分ける（プリペアドステートメントを徹底する）
3. 常に最新の情報を追う（フレームワークのアップデートを怠らない）
この3つを意識するだけで、あなたのWebサイトは格段に強固になります。セキュリティは「一度やって終わり」の作業ではなく、日々の習慣です。一歩ずつ、一緒に学んでいきましょう！
もし、「ここはどうコードを書けばいいの？」といった疑問があれば、いつでも聞いてくださいね。あなたのコードが、世界で一番安全な「家」になることを応援しています！
コメント