「ORMを使っているからSQLiは大丈夫」という慢心が、最も高くつく代償になる理由
現場でインシデント対応をしていると、「ORM（Object-Relational Mapping）を使っているからSQLインジェクション（SQLi）は対策済みです」と胸を張るエンジニアに度々出会います。
しかし、残念ながらORMは魔法の杖ではありません。むしろ、「ORMの便利さ」に隠れてSQLの生成ロジックがブラックボックス化し、開発者が「自分が投げているSQL」を意識しなくなった瞬間、脆弱性は忍び込みます。今日は、現場の最前線で見た「ORMの盲点」と、それを確実に潰すための実装術を共有します。
—
1. なぜORMを使っていてもSQLiが起きるのか
ORMがSQLiに対して安全なのは、あくまで「標準的なメソッド（find(), save(), where()など）」を正しく使っている場合に限られます。エンジニアが踏み抜く地雷は、主に以下の2パターンです。
1. 「生クエリ（Raw SQL）」の安易な利用: 複雑な集計やパフォーマンス要件で、ORMの抽象化を諦めて生SQLを書き、そこにユーザー入力を文字列結合してしまう。
2. 不適切なメソッド利用: 多くのORMには「条件式の一部を文字列として渡す」機能があります。これを「簡単だから」と安易に使うと、バックエンドでそのままSQLとして処理され、ゲームオーバーです。
攻撃者視点のPoC（概念実証）
例えば、ユーザーIDで検索する際に、ORMの機能を使ってこう書いてしまうケースです。
脆弱な例 (Djangoの例)
user_input = “‘1’ OR ‘1’=’1′” と入力されたら？
User.objects.extra(where=[“user_id = %s” % user_input])
この場合、extra() メソッドに渡された文字列はそのままSQLに連結されます。攻撃者は OR '1'='1' を注入することで、全ユーザーのデータを抜き取ることが可能です。ORMを使っているという安心感が、脆弱性を見逃す心理的バイアスになるのです。
—
2. 安全な実装パターン：ORMを「正しく」使い倒す
ORMを安全に使うための鉄則は、「ORMが提供するプレースホルダ機能から一歩も外に出ない」ことです。文字列結合によるクエリ構築を絶対に行ってはいけません。
実装例：Python (SQLAlchemy / Django)
安全な実装では、必ずORMが提供するパラメータバインド機能を使用します。
安全な実装：パラメータを分離して渡す
Djangoの場合：ORMのfilterメソッドは内部的にプリペアドステートメントを使用する
user = User.objects.filter(user_id=user_input).first()
生SQLを使う必要がある場合でも、必ずバインド変数を使う
from django.db import connection
with connection.cursor() as cursor:
# SQL文とパラメータを分離して実行（ORMが適切にエスケープする）
cursor.execute(“SELECT FROM users WHERE user_id = %s”, [user_input])
row = cursor.fetchone()
実装例：Node.js (Sequelize)
JavaScript環境でも同様です。where句にオブジェクトを渡すか、バインド変数を使用してください。
// 安全な実装：オブジェクト形式で条件を指定
const user = await User.findOne({
where: {
userId: userInput // Sequelizeが適切にエスケープ処理を行う
}
});
// 生クエリが必要な場合も、replacementsを利用する
const users = await sequelize.query(
‘SELECT FROM users WHERE status = :status’,
{
replacements: { status: ‘active’ },
type: QueryTypes.SELECT
}
);
—
3. インフラ層での二重防衛（多層防御）
アプリケーションの修正は必須ですが、万が一のSQLiに備え、DBへの接続権限管理（IAM等）も重要です。
- 最小権限の原則: Webアプリケーションが接続するDBユーザーには、
DROP TABLEやGRANTなどの権限を与えてはいけません。SELECT,INSERT,UPDATEのみに制限しましょう。 - WAFの活用: AWS WAFなどのマネージドルールを適用し、代表的なSQLiパターンをブロックします。
Nginx設定例（SQLiの代表的なクエリをブロックする設定）
URLやパラメータに明らかなSQLiのシグネチャが含まれる場合、403を返す
※ただし、これはあくまで補助的手段であり、アプリ修正の代わりにはならない
if ($query_string ~ “(union|select|insert|delete|drop|update|–|#)”) {
return 403;
}
—
最後に：シニアエンジニアからのアドバイス
「ORMがエスケープしてくれるから大丈夫」という考え方は捨ててください。「ORMはSQL生成器であり、その生成ロジックにユーザー入力を混ぜる行為は、直にSQLを書くのと同じリスクがある」と認識すること。
コードレビューの際は、「このクエリはパラメータが適切に分離されているか？」を常にチェックしてください。もし「面倒だから」という理由でRaw SQLに手を出そうとしているメンバーがいたら、その手を止めてペアプログラミングを提案しましょう。
セキュリティは「ツール」ではなく「規律」です。堅牢なシステムは、こうした小さなこだわりと、泥臭い確認の積み重ねから生まれます。明日からの開発で、ぜひこの意識を徹底してください。
コメント