ORMという「甘い罠」：なぜあなたのコードはSQLインジェクションを許すのか
現場でコードレビューをしていると、未だに「ORMを使っているからSQLインジェクションは大丈夫ですよね？」という若手エンジニアの問いかけに出くわす。結論から言おう。ORMは銀の弾丸ではない。むしろ、ORMの抽象化レイヤーが開発者の「SQLへの警戒心」を麻痺させ、より巧妙な攻撃の踏み台にされるケースが増えている。
今日は、HibernateやEntity Framework、あるいはPHPのEloquentやPythonのSQLAlchemyといったORMを扱う際に、なぜ「生のSQL（ネイティブクエリ）」が劇薬となり得るのか、そしてどうすれば安全に運用できるのかを解説する。
—
1. なぜORMを使っていても「射抜かれる」のか
多くのエンジニアは、ORMの find() や save() メソッドが自動的にプリペアドステートメント（パラメトリッククエリ）を発行してくれることを知っている。しかし、複雑な集計クエリやパフォーマンス最適化のために「ネイティブクエリ」を呼び出した瞬間に、その保護は解除される。
PoC：無防備なネイティブクエリの末路
例えば、Node.js (Sequelize) でユーザー入力をそのまま文字列結合してネイティブクエリを投げたとしよう。
// 【危険なコード】絶対に真似してはいけない
const userId = req.query.id; // 攻撃者が “; DROP TABLE users; — を仕込む
const result = await sequelize.query(SELECT FROM users WHERE id = ${userId});
このコードに対し、攻撃者は 1; DROP TABLE users; -- を送信する。結果として、アプリケーションはあなたの意図しない命令をDBに送り、テーブルが消滅する。ORMを使っているという安心感が、「入力のサニタイズを怠る」という致命的なヒューマンエラーを生んでいるのだ。
—
2. セキュアな実装：プリペアドステートメントの強制
ORMを使う最大のメリットは、「型安全なクエリ構築」にある。生のSQLを書くのは、どうしてもパフォーマンスや複雑な結合が必要な「最終手段」だけにするべきだ。
Python (SQLAlchemy) によるセキュアな実装例
SQLAlchemyを使用する場合、クエリパラメータを辞書形式で渡すことで、ORMが自動的にプリペアドステートメントとして処理する。
from sqlalchemy import text
【安全なコード】パラメータ化クエリを使用
def get_user_by_id(session, user_id):
# :user_id というプレースホルダを定義
stmt = text(“SELECT FROM users WHERE id = :user_id”)
# 辞書形式で安全に値をバインドする
result = session.execute(stmt, {“user_id”: user_id}).fetchone()
return result
この書き方であれば、user_id に何が入ってこようと、DBドライバ側で「値」としてエスケープされるため、SQLインジェクションは物理的に不可能になる。
—
3. 運用現場で課すべき「鉄の掟」
コードレベルでの修正に加え、インフラ側で「最悪の事態」を防ぐための多層防御を敷くのが、我々のようなセキュリティエンジニアの役割だ。
① アプリケーションユーザーの権限最小化
WebアプリがDBに接続する際のユーザー権限は、DROP TABLE や GRANT を実行できる db_admin 権限である必要はない。
— AWS RDS等の設定例：アプリ用ユーザーにはDML権限のみを付与
GRANT SELECT, INSERT, UPDATE, DELETE ON my_app_db. TO ‘app_user’@’web_server_ip’;
— DROP や ALTER などのDDL権限は決して付与しない
② WAFでのSQLインジェクション対策
AWS WAFやCloudflare等のエッジ側で、一般的なSQLインジェクションのパターン（UNION SELECT, OR 1=1 など）をフィルタリングするのは必須のガードレールだ。
AWS WAF (Managed Rule) の考え方:
AWSManagedRulesSQLiRuleSetを有効化する。- ただし、これだけで満足してはいけない。WAFはあくまで「既知の攻撃パターン」を弾くものであり、ゼロデイやロジック攻撃には対応できないからだ。
—
4. 最後に：セキュリティは「性悪説」で設計せよ
「ORMがよしなにやってくれる」という思い込みは捨てろ。ORMはあくまでDB操作を便利にするための道具であり、セキュリティ装置ではない。
現場で私がチームに徹底させているのは以下の3点だ。
1. ネイティブクエリは原則禁止: どうしても必要な場合のみ、セキュリティレビューを通すこと。
2. パラメータバインドの徹底: 文字列結合 (+ や ${}) を見つけたら、それはバグ修正レベルで差し戻す。
3. 静的解析ツールの導入: SonarQube や Snyk をCI/CDパイプラインに組み込み、生のSQL生成箇所を機械的にアラートさせる。
セキュリティは、美しいコードを書くこと以上に「泥臭い確認」の積み重ねだ。今日のこの知識を、明日のコードレビューで活かしてほしい。君たちのコードが、誰かの大切なデータを守る砦になることを期待している。
コメント