こんにちは！セキュリティの世界へようこそ。
新人のIT担当者の皆さんや、これから安全なWebアプリを作ろうと意気込んでいる開発者の皆さん、日々の開発お疲れ様です。
いきなりですが、「SQLインジェクション」という言葉、聞いたことはありますか？
名前からして何やら物騒で、エンジニアなら誰もが恐れるサイバー攻撃の一つです。ニュースなどで「個人情報が流出しました」という事件を聞くことがありますが、その原因の上位常連がこのSQLインジェクションなんです。
今回は、この厄介な攻撃の仕組みと、それをキレイに防いでくれる「プリペアドステートメント（事前準備された文）」という強力な盾について、身近な例えを交えながら優しく紐解いていきたいと思います。一歩ずつ、しっかりと安全なコードの書き方を学んでいきましょう！
—
1. 泥棒は「データのすき間」を狙ってくる！
まずは、攻撃のメカニズムをイメージしてみましょう。
Webサイトのログイン画面や検索窓を思い浮かべてください。私たちはそこに「ユーザー名」や「検索ワード」を入力しますよね。この入力された「データ」は、裏側でデータベース（DB）を操作するための言葉（SQL）と組み合わされて処理されます。
ここで、身近な「宅配ボックス」に例えてみましょう。
- 正しい使い方: 住人が暗証番号（データ）を入力して、荷物を取り出す。
- 危険な状態: 宅配ボックスの暗証番号を入力するテンキーの横に、なぜか「ボックスの鉄板ごとこじ開けるバール」が置いてあるような状態。
従来の古いプログラムでは、ユーザーが入力した文字を、そのままSQL文の文字列に「ガチャン！」とくっつけて実行していました。
例えば、「山田さん」を検索するはずのプログラムに、悪意ある人が山田' OR '1'='1なんていう特殊な言葉を入力したとします。
すると、プログラムはこう解釈してしまいます。
「おっ、データの中に別の命令（SQLの構文）が混ざっているぞ？ じゃあ、その命令通りにデータベースの全ユーザーデータを出しちゃおう！」
これがSQLインジェクションの正体です。つまり、「入力されたデータ」と「命令するプログラムの構造」を同じお皿に混ぜてしまったことがすべての原因なんです。
—
2. 救世主「プリペアドステートメント」の仕組み
この問題を根本から解決するのが、今回主役のプリペアドステートメント（Prepared Statement）です。日本語では「事前準備された文」と言います。
これまた例え話をしますね。
役所の窓口を想像してください。
1. 【事前準備（Prepare）】
窓口の職員が、あらかじめ「私はこれから『〇〇さん』という名前のデータを受け取って、住民票を探す作業をします」という仕事の型（テンプレート）をカチッと決めます。この時点では、まだ具体的な名前は入れません。
2. 【データの投入（Execute）】
後から、私たちが「山田」という文字を渡します。職員は、「あ、この文字はあくまで『〇〇さん』という枠に当てはめるただの文字列（データ）だな」と厳格に区別して処理します。
つまり、プリペアドステートメントを使うと、「SQLの命令（構造）」と「ユーザーが入力したデータ」が絶対に混ざらなくなるのです。
たとえユーザーが入力欄に OR '1'='1 のような怪しい攻撃コードを入力したとしても、データベースはそれを「ただの変な名前の人間（または文字列）」として扱うだけで、命令として実行することは一切ありません。完璧な防犯対策ですよね！
—
3. 実践！PHPとPDOを使った安全なコード
百聞は一見にしかず。実際に、PHPの代表的なデータベース接続機能である PDO（PHP Data Objects） を使って、安全なプリペアドステートメントの実装を見てみましょう。
以下のコードは、ユーザー名からユーザー情報を安全に検索するサンプルです。
<?php
// データベースへの接続設定（ホスト名、データベース名、文字コードなど）
$host = '127.0.0.1';
$db = 'sample_db';
$user = 'db_user';
$pass = 'secret_password';
$charset = 'utf8mb4';
$dsn = "mysql:host=$host;dbname=$db;charset=$charset";
$options = [
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, // エラー時は例外を投げる
PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC, // 連想配列で結果を取得
PDO::ATTR_EMULATE_PREPARES => false, // ★超重要：本物のプリペアドステートメントを使用する
];
try {
// 1. データベースに接続
$pdo = new PDO($dsn, $user, $pass, $options);
// 2. ユーザーからの入力を受け取る（ここでは仮に変数としておきます）
$input_username = $_POST['username'] ?? 'yamada';
// 3. 【プリペアドステートメントの準備】
// 実際のデータの代わりに「プレースホルダー（:username）」を置いたSQLの型を用意します。
$stmt = $pdo->prepare('SELECT id, username, email FROM users WHERE username = :username');
// 4. 【データのバインドと実行】
// プレースホルダーに実際の入力値を安全に割り当てて、クエリを実行します。
// ここで渡された値は、SQLの構造を変える力を持たない「ただの文字列」として安全に処理されます。
$stmt->execute([':username' => $input_username]);
// 5. 結果の取得
$user_data = $stmt->fetch();
if ($user_data) {
echo "ようこそ、" . htmlspecialchars($user_data['username'], ENT_QUOTES, 'UTF-8') . "さん！";
} else {
echo "ユーザーが見つかりませんでした。";
}
} catch (\PDOException $e) {
// エラーハンドリング（本番環境では詳細なエラーメッセージを画面に出さないよう注意しましょう）
echo "データベース処理でエラーが発生しました。";
// error_log($e->getMessage()); // ログには詳細を残す
}
?>コードのポイント解説
$pdo->prepare(...)の部分で、あらかじめSQLの骨組みをデータベースに教えています。:usernameという部分が「プレースホルダー（データの入り口）」です。ここに直接ユーザーの入力を文字列結合してはいけません（WHERE username = '. $input_username .'のような書き方は絶対にNGです！）。$optionsの中のPDO::ATTR_EMULATE_PREPARES => falseは、PHP側での疑似的な置き換えではなく、データベースサーバー側の本物のプリペアドステートメント機能を使うための重要な設定です。必ずfalseに設定するようにしましょう。
—
4. 最後に：安全な開発を習慣化しよう
いかがでしたでしょうか？
「SQLインジェクション」という言葉は難しく聞こえますが、要するに「プログラムの命令文とユーザーの入力を一緒くたに混ぜてしまうな」という、料理や整理整頓に通じるシンプルなルールを守るだけで防ぐことができます。
新しいシステムや機能を開発するたびに、「ここにプリペアドステートメントは使われているか？」「文字列を直接結合していないか？」と、自分のコードを優しく見つめ直す習慣をつけてみてください。
一歩ずつ確実な知識を身につけて、狙われにくい強固なWebアプリを作っていきましょう！それでは、次のセキュリティ解説でお会いしましょう。
コメント