Django ORMの「神話」と、生のSQLが暴く脆弱性の深淵
多くのエンジニアが「Djangoを使っているからSQLインジェクションは大丈夫」と安易に信じ込んでいる。これは半分は正しく、半分は危険な誤解だ。
確かに、DjangoのORM（Object-Relational Mapping）は、内部的にプレースホルダー（バインド変数）を強制する設計になっている。だが、我々のようなセキュリティアーキテクトから見れば、ORMという抽象化レイヤーは「魔法の盾」ではなく、単なる「インターフェース」に過ぎない。その裏側で何が起きているのか、なぜ「Raw SQL」がブラックホールへと繋がるのか、その低レイヤの挙動を紐解こう。
1. ORMが「安全」である理由：抽象化の裏側にあるバインド変数
DjangoのORMメソッド（`filter()`, `get()`, `exclude()`など）は、開発者が書いたクエリセットをDBドライバのレベルで完全に分離する。具体的には、SQL文の骨格とユーザー入力を別々のパケットとしてDBエンジンに渡す仕組みだ。
例えば `User.objects.filter(username=user_input)` と書いた場合、Djangoは内部的に以下のようなSQLを構築する。
— 実際にはドライバレベルでパラメータ化される
SELECT FROM auth_user WHERE username = %s;
ここで重要なのは、`%s` の部分に何が入っても、DBエンジンはそれを「データ」としてのみ解釈し、「命令（コマンド）」としては絶対に実行しないという点だ。攻撃者が `’ OR 1=1 –` のような悪意ある文字列を混入させても、DBはそれを「`’ OR 1=1 –` という名前のユーザー」を探す検索クエリとして処理する。ここにSQLインジェクションの付け入る隙はない。
2. 「raw()」という禁断の果実：なぜ脆弱性が生まれるのか
しかし、複雑な集計クエリや、ORMの表現力を超える最適化が必要な時、我々は `Manager.raw()` や `connection.cursor().execute()` を使わざるを得ない。ここで多くのエンジニアが犯す最大のミスが、「Pythonの文字列フォーマット（f-stringsや%演算子）を直接SQL文字列に埋め込むこと」だ。
脆弱なコードの典型（絶対にやるな）
致命的な脆弱性：SQL文字列をPythonで動的に結合している
def get_user_bad(user_id):
query = f”SELECT FROM users WHERE id = {user_id}” # 最悪のパターン
return User.objects.raw(query)
このコードを実行すると、攻撃者は `user_id` に `1; DROP TABLE users; –` を注入するだけで、データベースを全滅させることができる。これは、パーサーが命令とデータを区別できなくなる「コンテキストの混濁」が引き起こす根本的な脆弱性だ。
3. 安全なRaw SQLの作法：パラメータ化の鉄則
生のSQLを実行する場合、必ずDBAPI 2.0のパラメータ置換メカニズムを利用しなければならない。Djangoの `raw()` メソッドには、第二引数として `params` を渡すためのインターフェースが用意されている。
安全な実装例
def get_user_safe(user_id):
# クエリ本体にはプレースホルダー（%s）のみを記述する
sql = “SELECT FROM users WHERE id = %s”
# データはタプルまたはリストとして切り離して渡す
params = [user_id]
# Djangoは内部でDBドライバにこのパラメータを渡し、安全にバインドさせる
return User.objects.raw(sql, params)
この実装であれば、たとえ `user_id` に攻撃コードが仕込まれていても、DBドライバはその値を一貫して「リテラル値」として扱う。命令とデータの分離は維持され、攻撃は防がれる。
4. セキュリティアーキテクトとしての視点：境界防御と多層防御
現代のアプリケーションセキュリティは、ORMの防衛力だけでは不十分だ。特に生成AIの台頭により、プロンプトインジェクションとSQLインジェクションが複雑に絡み合う攻撃シナリオも想定しなければならない。
- ホワイトリストによる検証: 入力値が整数であるべきなら、SQLに渡す前に型変換（`int(user_input)`）を強制せよ。
- データベース権限の最小化: アプリケーション用DBユーザーには `DROP TABLE` や `GRANT` などのDDL権限を与えてはならない。万が一SQLインジェクションを許しても、被害を「データの読み取り」のみに限定させるのがアーキテクトの矜持だ。
- クエリの可視化と監査: Djangoの `django.db.backends` ロガーを監視し、予期せぬ Raw SQL や、ORMが生成する異常に巨大なクエリを検知するSIEM環境を構築せよ。
最後に：盲信を捨て、構造を疑え
DjangoのORMは強力なツールだが、それは「適切に使った場合」という条件付きの免罪符だ。我々セキュリティの専門家が目を光らせるべきは、ORMという抽象化層が破綻する「境界線」、つまりRaw SQLが使われる場所、あるいは複雑なクエリセットの裏にある低レイヤの通信プロトコルだ。
コードを眺める時、「このデータはどこから来て、どのようにSQLのコンテキストに合流するのか」を常に自問自答してほしい。その疑い深さこそが、最強の防衛となる。
コメント