こんにちは！セキュリティチームで日々、泥臭いインシデントの分析や脆弱性ハンティングを行っているホワイトハッカーの私です。
今回は、Web開発の現場で最も恐れられている、そして今なお世界中で猛威を振るっている「インジェクション攻撃（特にSQLインジェクション）」の防御について、新人のIT担当者や「セキュリティって難しそう…」と身構えてしまう開発者の方向けに、実例を交えて優しく紐解いていきたいと思います。
「暗号理論やエンドポイントの話じゃないの？」と思ったそこのあなた。実は、データを安全に扱い、データベースを守る仕組みも、強固な城壁を作るための暗号技術と同じくらい、モダンなWebセキュリティの根幹をなす必須教養なんです。
一歩ずつ、身近な防犯の例えから紐解いていきましょう！
—
1. 泥棒の心理とSQLインジェクションの仕組み
まずは、私たちが日々対峙している「SQLインジェクション」がどんな手口なのか、身近な「家の鍵とインターホン」に例えて考えてみましょう。
想像してみてください。あなたの家の玄関には、名前（ID）と合言葉（パスワード）を入力して解錠する最新のスマートロックがあるとします。来客がインターホン越しに自分の名前と合言葉を伝えると、システム（執事のような存在）がそれを確認してドアを開けますよね。
プログラムの裏側で動いているSQLもこれと全く同じです。例えば、「ユーザー名でデータベースを検索する」という処理は、裏で次のような命令文（SQL）を組み立てています。
-- データベースに対する通常の検索命令
SELECT * FROM users WHERE username = '入力された名前';さて、ここで悪意ある攻撃者（泥棒）が現れました。彼は真っ当に名前を入力する代わりに、こんな文字列を入力してきました。
' OR '1'='1
これをそのまま先ほどの命令文に当てはめると、どうなるでしょうか？
-- 攻撃者が入力値をそのまま埋め込んでしまった危険な状態
SELECT * FROM users WHERE username = '' OR '1'='1';お気づきでしょうか？ 「'1'='1'」という条件は常に「正しい（真）」になってしまいます。その結果、データベースの執事は「おっ、条件が成立したな！」と勘違いし、パスワードの確認すらスキップして、全ユーザーのデータを攻撃者に差し出してしまうのです。
これが、SQLインジェクション（命令の注入攻撃）の恐ろしいメカニズムです。攻撃者は、入力欄という「ただの郵便受け」に、プログラムを破壊する「爆弾（悪意あるコード）」を混ぜ込んでいるわけですね。
—
2. 泥棒を完全にシャットアウトする「2つの鉄則」
では、この巧妙な手口からシステムを守るにはどうすればよいのでしょうか？
私たちが現場で口を酸っぱくして言う防御策は、たったの2つです。
1. プリペアドステートメント（準備された文）の強制
2. 入力値の厳格なホワイトリスト検証
この2つを、防犯の例えで分かりやすく解説しますね。
鉄則1：プリペアドステートメント ＝ 「窓口の透明なアクリル板」
先ほどの一番の問題点は、「入力された文字列を、そのままプログラムの命令の一部として実行してしまったこと」にあります。
これを防ぐのがプリペアドステートメントです。
銀行の窓口を想像してください。あなたと行員の間には、頑丈なアクリル板がありますよね。あなたは書類に「振込先」や「金額」という「データ」だけを書き、行員は「あらかじめ決められた手順（命令）」に従って処理を行います。あなたがどんなに「全財産を私にくれ！」と紙に書いたとしても、窓口の行員はそれを「命令」ではなく「ただの文字列（データ）」として処理するため、システムが乗っ取られることはありません。
プログラムの世界でも全く同じです。あらかじめ「ここにはただの文字（データ）が入りますよ」とデータベースに予約席を作っておき、後から入力値を安全に流し込む。これがプリペアドステートメントの正体です。
鉄則2：ホワイトリスト検証 ＝ 「厳格な招待客リスト」
もう一つの防御策がホワイトリスト検証です。
セキュリティの世界では、「信用するな、検証しろ（Trust, but verify）」が鉄則です。
「泥棒かもしれないから怪しいやつを排除しよう（ブラックリスト方式）」ではなく、「事前にパスポートを確認し、リストに載っている安全な人だけを通す（ホワイトリスト方式）」を採用します。
例えば、「年齢」を入力する欄であれば、文字ではなく「0から150までの半角数字」以外はすべて門前払いにする。郵便番号なら「ハイフンなしの7桁の数字」だけを許可する。このように、あらかじめ「これ以外の形はすべて不正とみなす」という厳しいルールを設けることで、攻撃の芽を完全に摘み取ることができます。
—
3. 【実務で使える】PHPとPDOによる安全なコード実装
それでは、理屈が分かったところで、実際の開発現場で使える「安全なコードの書き方」を見ていきましょう。今回は多くのWebシステムで使われているPHPと、標準的なデータベース接続機能であるPDO（PHP Data Objects）を例に挙げます。
まずは、絶対にやってはいけない「悪い例」から。
// 【危険な例】入力値をそのままSQL文に結合している（SQLインジェクションの温床）
$username = $_POST['username'];
$sql = "SELECT * FROM users WHERE username = '" . $username . "'";
$db->query($sql); // ここで攻撃されたら一網打尽です！上記のように、変数を直接文字列結合するのは、玄関の鍵をかけずに外出するようなものです。今すぐやめましょう。
続いて、私たちが現場で強く推奨する「正しい例（プリペアドステートメント）」です。
// 【安全な例】プレースホルダー（?）を使ってデータを完全に分離する
$username = $_POST['username'];
// 1. SQLの骨組みだけを先にデータベースに準備（プリペア）する
$stmt = $db->prepare('SELECT * FROM users WHERE username = ?');
// 2. 実行時に「これはただの文字列データですよ」と明示して安全に値をバインドする
$stmt->execute([$username]);
// 3. 結果を取得する
$user = $stmt->fetch();ご覧のとおり、? というプレースホルダー（身元引換券のようなもの）を置き、実際の値は execute メソッドの引数で安全に渡しています。これによって、たとえユーザーが OR '1'='1 と入力したとしても、データベース側はそれを「username というカラムに一致する文字列」としてしか扱わないため、攻撃は完全に無効化されます。
—
4. コマンドインジェクションへの応用と防御
さて、SQLインジェクションと並んで注意しなければならないのが「OSコマンドインジェクション」です。
これは、Webアプリから背後にあるOS（LinuxやWindowsなど）の機能を呼び出してファイルを操作したり、システム診断（ping コマンドなど）を行ったりする際に発生します。
例えば、ユーザーが入力したIPアドレスに対して ping を飛ばすような機能を考えてみましょう。
// 【非常に危険な例】ユーザーの入力をそのままOSのシェルに渡している
$ip = $_POST['ip_address'];
$output = shell_exec("ping -c 1 " . $ip);もしここで、ユーザーが 127.0.0.1; cat /etc/passwd のような文字列を入力したらどうなるでしょうか？
OSはセミコロン（;）を「命令の区切り」と解釈し、ping を実行したあとに、システムの重要なパスワードファイル（passwd）を盗み見る悪意あるコマンドまで実行してしまいます。
コマンドインジェクションを防ぐには？
OSコマンドインジェクションを防ぐための最善策は、「Webアプリから直接OSのシェルコマンドを呼び出さないこと」です。これに尽きます。
どうしても必要な場合は、以下のような徹底した対策を行います。
- シェルを介してコマンドを実行する関数（
shell_execやsystemなど）は極力使わない。 - パラメーターを直接渡すのではなく、言語が提供する安全なAPIや専用のライブラリを使用する。
- 先ほど解説した「ホワイトリスト検証」を厳格に行い、入力値が「正しいIPアドレスの形式（正規表現など）」に完全に一致している場合のみ処理を通す。
// 【安全な例】IPアドレスの形式（IPv4）に完全に一致するかホワイトリストで検証する
$ip = $_POST['ip_address'];
// 正規表現を使って、IPv4アドレスの形式以外は一切受け付けない
if (!filter_var($ip, FILTER_VALIDATE_IP, FILTER_FLAG_IPV4)) {
die("不正なIPアドレスの形式です。");
}
// 安全が確認できたため、システム固有の安全な関数やパラメータ処理を行う
// （※理想的には外部コマンドの実行自体を避けてください）—
5. まとめ：今日から始める第一歩
今回は、OWASP Top 10の常連であるインジェクション攻撃のメカニズムと、その鉄壁の防御戦略について解説してきました。
- SQLインジェクションには、文字列の直結合を捨て、プリペアドステートメントを強制する。
- コマンドインジェクションには、OSシェルの直接実行を避け、厳格なホワイトリスト検証で不正な入力を弾く。
セキュリティ対策というと、難解な暗号アルゴリズムや高価なセキュリティ製品の導入を思い浮かべるかもしれませんが、最も基本にして強力な防御壁は、「開発者一人ひとりの正しいコーディング習慣」に他なりません。
「動けばいいや」のコードから、「安全に動く美しいコード」へ。
今日の学びをあなたのプロジェクトに持ち帰り、ぜひ実務のコードレビューや実装に役立ててくださいね。一歩ずつ、安全なWebの世界を作っていきましょう！
コメント