ORMは「魔法の杖」ではない：SQLインジェクションを招くRaw Queryの罠
「ORMを使っているからSQLインジェクションなんて関係ない」。もし君がそう思っているなら、今すぐその考えを捨ててほしい。
現場で数多のインシデントを見てきたが、皮肉にも「ORMの利便性に甘えた結果、最も初歩的な脆弱性を埋め込んでしまった」というケースは後を絶たない。ORMはSQLの抽象化レイヤーだが、開発者が「複雑なクエリが書けない」と投げ出し、安易にRaw SQL（生クエリ実行機能）を使った瞬間、その堅牢な城壁には巨大な風穴が開く。
今日は、ORM利用者が陥る「生の罠」と、それを確実に封じ込めるための鉄則を叩き込む。
—
1. なぜORMを使っていても抜かれるのか？
ORM（Eloquent, SQLAlchemy, TypeORMなど）は、原則としてプレースホルダ（バインド変数）を自動的に使用する設計になっている。しかし、パフォーマンスチューニングや、どうしてもORMの記法では表現できない複雑な結合処理を行う際、開発者はDB::raw()やexecute()といった「生のSQLを投げる口」を開いてしまう。
問題は、その中に渡す文字列の組み立て方だ。
攻撃者が見ている「盲点」
攻撃者は、ORMが生成する美しいクエリなど見ていない。彼らが狙っているのは、開発者が「どうせ内部クエリだし、ユーザー入力なんて入ってこないだろう」と油断して書いた文字列結合だ。
脆弱なコードの例（Python/SQLAlchemyの悪しき例）
絶対にやってはいけない実装
user_input = request.args.get(‘user_id’)
悪意あるユーザーが “1 OR 1=1″ を入力したらどうなるか？
query = f”SELECT FROM users WHERE id = {user_input}”
result = db.session.execute(text(query))
このコードでは、user_idに1 OR 1=1が渡されると、データベースは全てのユーザー情報を吐き出す。ORMを使っているという安心感が、この「文字列をそのまま結合する」という致命的なミスを隠蔽してしまうんだ。
—
2. 脆弱性を完全に封じるための鉄則
解決策はシンプルだ。「どんな理由があっても、ユーザー入力を文字列結合でSQLに混ぜない」。これに尽きる。
鉄則1：プレースホルダを強制する
ORMが提供するAPIは、必ず「バインド変数」を受け入れるように設計されている。生のSQLが必要な場合でも、必ず変数を分離して渡すこと。
セキュアな実装（Python/SQLAlchemy）
from sqlalchemy import text
入力値は直接埋め込まず、パラメータ辞書として渡す
user_input = request.args.get(‘user_id’)
:user_id という名前付きプレースホルダを使用する
query = text(“SELECT FROM users WHERE id = :user_id”)
result = db.session.execute(query, {“user_id”: user_input})
これだけで、たとえuser_inputに悪意あるSQL文が混入していても、DBエンジンはそれを「ただの文字列」として処理する。SQLコマンドとして解釈されることは物理的にあり得ない。
—
3. 実務で使える防御の多層化設定
アプリケーション側の修正が基本だが、万が一のミスに備えてインフラ側でガードを固めるのは「プロの仕事」だ。
WAF（AWS WAFの推奨設定）
SQLインジェクションのパターンをシグネチャベースで弾くWAFは必須だ。AWS WAFを使用しているなら、SQL Injectionの管理ルールグループを有効にするだけで、基本的な攻撃の8割は防げる。
- Action: Block
- Rule Type: Managed Rule Groups ->
SQL database - Priority: 最優先（リクエストがアプリケーションに届く前に遮断する）
DBユーザーの権限最小化（IAM/DB権限）
これが最も泥臭く、かつ最も効果が高い防御策だ。Webアプリが接続するDBユーザーに、DROP TABLEやGRANT、TRUNCATEといった権限を与えていないか？
— 悪い例：アプリ用ユーザーに全権限を与えている
GRANT ALL PRIVILEGES ON my_db. TO ‘app_user’@’%’;
— 良い例：必要な権限のみに絞る
GRANT SELECT, INSERT, UPDATE ON my_db.users TO ‘app_user’@’%’;
— DROP や ALTER は絶対に不要。もし攻撃者にクエリを乗っ取られても、データベースそのものの破壊は防げる。
—
最後に：コードを書く君へ
セキュリティとは、何か特別なツールを導入することではない。「自分の書いたコードが、悪意ある人間にどう悪用されるか」を常に想像し、その想像の範囲をコードで物理的に封じ込める作業だ。
ORMのRaw SQL機能を使うときは、一度立ち止まって考えてほしい。「これは本当に生のクエリが必要か？」「プレースホルダで書けるのではないか？」。
君たちが書く一行のコードが、ユーザーの信頼を守る最後の砦だ。技術を信じすぎず、自分のコードを疑うこと。それが、真に信頼されるエンジニアへの第一歩だよ。
さて、次は君のプロジェクトのコードを見直してみようか。何か不安な箇所があれば、いつでも相談してくれ。
コメント