【実務・中級編】 SQLインジェクションを防ぐプリペアドステートメントの徹底 – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

おい、ちょっと手を止めてこっちを向いてくれ。

先日、とあるクライアントのWebアプリケーションのペネトレーションテストを実施したんだがね。ログインフォームに ' OR 1=1 -- をブチ込んだ瞬間、見事にデータベースの全ユーザーテーブルが画面上に吐き出された。令和のいま時、こんな教科書通りのSQLインジェクション（SQLi）が綺麗に刺さるとは思わなかったよ。開発チームのリーダーは真っ青になっていたが、現場のエンジニアたちは「まさか自分たちのコードで動的SQLを書いているとは思わなかった」と口を揃えていた。

お前たちはどうだ？「ウチはフレームワークを使っているから大丈夫」「ORMが勝手に守ってくれているはず」なんて、お花畑な思考停止に陥っていないだろうか。

今日は、数々の不正アクセス現場を踏んできた俺が、SQLインジェクションという古典的でありながら今なお最強クラスの凶悪な脆弱性について、攻撃者の視点と、それを完全に叩き潰すための実務的な防御策を叩き込んでやる。心して聞け。

—

なぜ未だにSQLインジェクションはなくならないのか？

攻撃者の視点から言わせてもらえば、SQLiほど「コスパが良い」脆弱性はない。URLのパラメータやPOSTのリクエストボディに少し奇妙な記号（' や ; など）を混ぜるだけで、データベースの裏側にあるOSのコマンド実行権限まで奪える可能性があるからだ。

多くの開発者が勘違いしているのは、「エスケープ処理をしているから安全」という神話だ。例えば、入力値に含まれるシングルクォートを \' に置換するような自前の一文字エスケープ。これは文字コードのエンコーディングの不一致（いわゆるSJISのマルチバイト文字絡みの問題など）を突かれた瞬間に簡単にバイパスされる。ブラックリスト方式や場当たり的なサニタイジングは、攻撃者にとっては格好のオモチャでしかない。

根本的な悪の根源は、「SQL文の構造（コマンド）」と「ユーザーからの入力値（データ）」を同じ文字列として結合してデータベースに投げる設計そのものにある。

—

攻撃者のPoC：何が起きているのか

まずは、脆弱なコードがどのように裏側で崩壊するのか、そのメカニズムを理解しておこう。以下のPHPコードを見てほしい。最悪なアンチパターンだ。

// 【絶対に真似してはいけない危険なコード】
$username = $_POST['username'];
$password = $_POST['password'];

// ユーザー入力をそのままSQL文字列に結合している
$query = "SELECT * FROM users WHERE username = '$username' AND password = '$password'";
$result = mysqli_query($conn, $query);

もし、攻撃者が username フォームに以下のペイロードを入力したらどうなるか。

admin' OR '1'='1

生成されるSQL文はこう変貌する。

SELECT * FROM users WHERE username = 'admin' OR '1'='1' AND password = '...'

'1'='1' は常に真（True）になるため、パスワードの検証が丸無視され、攻撃者は admin 権限をいとも簡単に奪取してしまう。これが情報漏洩インシデントの典型的な幕開けだ。

—

完全に防御するための鉄則：プリペアドステートメントの強制

この地獄絵図を防ぐ唯一にして最大の特効薬が、「プリペアドステートメント（準備された文）」と「バインド機構」の徹底だ。

プリペアドステートメントの思想はシンプルかつ強力である。
1. 先にSQLの「構造」だけをデータベースエンジンに送り、コンパイル（準備）させる。
2. その後、ユーザーからの「入力値」を後から安全なデータとして流し込む。

データベース側は、入力値を「ただの文字列データ」として扱うため、たとえ入力値の中に OR 1=1 や悪意あるSQL文が混ざっていても、それは単なる「username というカラムに一致する文字列」として処理され、構文が書き換わることは絶対にない。

1. PHP (PDO) によるセキュアな実装サンプル

現代のPHP開発において、mysqli の生クエリや古い関数を使う理由はない。必ず PDO (PHP Data Objects) を使い、プレースホルダ（? または名前付きパラメータ）を利用しろ。

<?php
/**
 * セキュアなログイン認証処理のサンプル (PHP PDO)
 */
try {
    // データベース接続 (文字コードは必ずUTF-8を指定)
    $dsn = "mysql:host=127.0.0.1;dbname=app_db;charset=utf8mb4";
    $options = [
        PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, // エラー時は例外を投げる
        PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC,
        PDO::ATTR_EMULATE_PREPARES   => false, // ★超重要：エミュレートをオフにしてネイティブのプリペアドステートメントを使う
    ];
    $pdo = new PDO($dsn, 'app_user', 'secure_password', $options);

    // 1. SQLの骨組み（構造）だけを先に対象に送る（プレースホルダ ':username' を使用）
    $stmt = $pdo->prepare('SELECT id, username, password_hash FROM users WHERE username = :username');

    // 2. ユーザー入力をバインド変数として安全に渡す
    $inputUsername = $_POST['username'] ?? '';
    
    // execute時に配列でデータを渡すことで自動的にサニタイジングと同等の安全性が担保される
    $stmt->execute(['username' => $inputUsername]);
    $user = $stmt->fetch();

    if ($user && password_verify($_POST['password'], $user['password_hash'])) {
        // ログイン成功処理
        echo "ログイン成功！ようこそ、" . htmlspecialchars($user['username'], ENT_QUOTES, 'UTF-8') . "さん。";
    } else {
        // セキュリティ上の理由から「ユーザー名またはパスワードが違います」と一律で返す
        echo "認証に失敗しました。";
    }

} catch (PDOException $e) {
    // 本番環境では詳細なエラーメッセージを画面に出力せず、ログに吐き捨てること
    error_log("Database Error: " . $e->getMessage());
    echo "システムエラーが発生しました。管理者に連絡してください。";
}
?>

2. Python (Django / SQLAlchemy) のケース

PythonでWebアプリを作る場合、Django ORMやSQLAlchemyを使っているからといって安心しきってはいけない。ORM経由であれば基本的にはプリペアドステートメントが使われるが、.raw() メソッドや text() クエリで生SQLを直書きした瞬間に脆弱性が復活する。

以下は、SQLAlchemyで生に近いクエリを書く場合の安全な実装例だ。

from sqlalchemy import create_engine, text
from sqlalchemy.orm import sessionmaker

# エンジン作成
engine = create_engine("postgresql+psycopg2://app_user:password@localhost/app_db")
Session = sessionmaker(bind=engine)
session = Session()

def get_user_safely(username_input: str):
    # 【安全な実装】パラメータを辞書形式で渡す
    # text()を使用する場合でも、コロン(:username)でプレースホルダを定義する
    query = text("SELECT id, username FROM users WHERE username = :username")
    
    # executeの第二引数にパラメータを渡すことで、ドライバ側で安全にバインドされる
    result = session.execute(query, {"username": username_input}).fetchone()
    
    if result:
        return dict(result._mapping)
    return None

もしここで text(f"SELECT ... WHERE username = '{username_input}'") なんて文字列フォーマットを使っていたら、即座にコードレビューで差し戻しどころか、チームからレッドカードをもらうべきだ。

—

防御の縦深防御：データベースユーザーの「最小権限の原則」

アプリケーションコードでどれだけ完璧にプリペアドステートメントを実装していたとしても、万が一、ゼロデイ脆弱性やファイルアップロード脆弱性など、他のルートからRCE（リモートコード実行）やSQLiを許してしまった時のために、「データベース側の権限設計」が最後の砦（セーフティネット）になる。

多くの開発現場でやりがちなのが、Webアプリが接続するデータベースユーザーに root や sa、あるいは ALL PRIVILEGES をそのまま与えているケースだ。これは「鍵をかけ忘れた金庫の前に、全財産の入ったトランクを置いておく」ようなものだ。

実務でデータベースユーザー権限を設計する際は、以下のポリシーを厳守しろ。

1. DDL（CREATE, DROP, ALTER等）の禁止: アプリケーション用ユーザーには、テーブル構造を変更する権限を絶対に与えない。
2. DMLの最小化: 必要最低限のテーブルに対してのみ、SELECT, INSERT, UPDATE のみを許可する（必要がなければ DELETE すら剥奪せよ）。
3. システムカタログへのアクセス禁止: information_schema やシステムテーブルへの過剰なアクセス権限を絞る。

MySQLでの最小権限ユーザー作成の例

-- アプリケーション用の専用ユーザーを作成（外部からの不審な接続を防ぐためホストを限定）
CREATE USER 'app_web_user'@'10.0.1.15' IDENTIFIED BY 'VeryStrongAndComplexPasswordHere!';

-- 特定のデータベースに対してのみ、必要な操作権限を付与する
GRANT SELECT, INSERT, UPDATE ON app_db.users TO 'app_web_user'@'10.0.1.15';
GRANT SELECT, INSERT ON app_db.audit_logs TO 'app_web_user'@'10.0.1.15';

-- 権限を即座に反映
FLUSH PRIVILEGES;

万が一、アプリの別の箇所の脆弱性からSQLiを踏み台にされたとしても、この権限設定であれば、他のデータベースやテーブル（例えば決済情報や管理者のパスワードハッシュが格納された別テーブル）を丸ごと引っこ抜かれるリスクを劇的に低減できる。これが「縦深防御」の考え方だ。

—

チーフエンジニアからの総括：明日からチームでやるべきこと

さて、ここまで読んで「ウチのコード、大丈夫かな…」と冷や汗をかいたエンジニアもいるだろう。安心しろ、気づいた今が直すタイミングだ。明日からチームで以下のアクションを即座に実行してほしい。

1. 静的解析ツール（SAST）やLinterの導入: GitHub ActionsやGitLab CIのパイプラインに、SQLインジェクションの兆候（生SQLの文字列結合など）を検知するルールを組み込め。
2. コードレビューの厳格化: プルリクエストのレビュー時には、「動的なSQL生成をしていないか」「ORMのrawクエリで変数を直結していないか」をチェックリストの最優先事項に据えろ。
3. DB接続設定の確認: アプリケーションが使っているDBユーザーの権限が root になっていないか、今すぐ確認して最小権限に絞り直せ。

セキュリティは「完璧な一度きりの対策」ではなく、泥臭い日々の点検と正しい設計の積み重ねだ。後輩たちが安全なコードを書ける環境を作るのは、他でもない、シニアである俺たちやお前の仕事だ。頼むぞ。

スポンサーリンク

コメント

タイトルとURLをコピーしました