Django ORMの「魔法」を過信するな：SQLインジェクションの深淵と正しい武装術
現場でコードレビューをしていると、「Djangoを使っているからSQLインジェクションなんて関係ないよね？」という、冷や汗が出るようなセリフを耳にすることがある。
結論から言おう。Django ORMは強力だが、それは「使い方を間違えない」ことが大前提だ。
セキュリティの現場で我々が対峙するのは、フレームワークの脆弱性ではなく、「開発者が便利さに溺れて踏み抜いた実装の地雷」だ。今日は、DjangoのORMがどのようにSQLを安全に処理しているのか、そして「生SQL（Raw SQL）」という名のパンドラの箱を開ける時に何をすべきかを、実務的な視点で深掘りする。
—
1. なぜDjango ORMは「基本的には」安全なのか
Django ORMがSQLインジェクションに対して強いのは、内部で「パラメータ化クエリ（プリペアドステートメント）」を強制しているからだ。
例えば、`User.objects.filter(username=user_input)` と書いたとき、DjangoはSQLを組み立てる際に、値を直接文字列結合するのではなく、値をプレースホルダ（`%s`や`?`など）に置き換え、クエリと値を分離してデータベースドライバに渡す。
つまり、データベース側で「これは命令ではなく、ただの文字列である」と解釈されるため、たとえ攻撃者が悪意あるSQL文を入力しても、単なる「名前」として検索されるだけで終わる。これが現代のWeb開発における「防弾チョッキ」だ。
—
2. 危険領域：`raw()` メソッドという地雷原
しかし、パフォーマンスチューニングや複雑な集計のために `raw()` を使う瞬間、その防弾チョッキを自ら脱ぐことになる。多くのエンジニアが犯す致命的なミスがこれだ。
脆弱な実装例（絶対にやってはいけない）
最悪のコード：文字列フォーマットでSQLを組み立てている
user_input = “‘ OR ‘1’=’1″
query = f”SELECT FROM myapp_user WHERE username = ‘{user_input}'”
users = User.objects.raw(query) # 攻撃者は全ユーザー情報を引き抜ける
このコードを実行した瞬間、アプリケーションは無防備になる。攻撃者は `username` フィールドを経由して、テーブル構造の破壊やデータ流出を自由に行える。
安全な実装例（パラメータ化の徹底）
`raw()` を使う場合も、必ず「パラメータバインディング」を行わなければならない。
正しい実装：クエリとパラメータを分離する
user_input = “target_user”
第2引数に辞書やリストで値を渡すのが鉄則
query = “SELECT FROM myapp_user WHERE username = %s”
users = User.objects.raw(query, [user_input])
このように書けば、Djangoは内部的にパラメータ化クエリを生成してくれる。「クエリ文の中に直接変数を埋め込まない」。これが鉄則だ。
—
3. 実践：万が一のインジェクションを検知・防御する防壁
開発レベルでの防御は必須だが、インシデント対応のプロとしては「多層防御」を推奨する。もし実装にミスがあっても、最終的に被害を食い止めるためのレイヤーが必要だ。
WAF（ModSecurity / AWS WAF）による検知
SQLインジェクションのパターンは、WAFで比較的容易に遮断できる。例えばAWS WAFであれば、`SQL injection (SQLi) rule` を有効にするだけで、一般的な攻撃コードの大部分を弾ける。
AWS WAF設定のポイント:
- SQLiルールセットの適用: 「Generic SQL Injection」を選択する。
- 誤検知の調整: 必要に応じて特定のパス（管理画面等）のみルール強度を上げる。
データベースユーザーの権限最小化
そもそも、Djangoが接続するDBユーザーに、そのアプリが不要な権限を与えていないか？
— 悪い例: データベース全体のDROP権限やGRANT権限をアプリに与えている
— 良い例: 必要なテーブルのみ、SELECT, INSERT, UPDATE, DELETE権限のみを付与する
GRANT SELECT, INSERT, UPDATE, DELETE ON myapp_db. TO ‘django_user’@’localhost’;
もしSQLインジェクションが成功しても、この設定があれば「テーブルのドロップ」や「システム情報の流出」という最悪の事態は防げる。
—
4. チーフエンジニアからの提言：コードレビューで見るべき盲点
最後に、チームのリーダーとして若手に必ず伝えていることを共有する。
1. `extra()` や `raw()` は「最終手段」と心得よ:
ORMで書けるなら、それが最も安全だ。わざわざ生SQLを書く必要性を論理的に説明できないコードは、レビューを通さない。
2. ログを見ろ:
開発環境のログには、ORMが生成した実際のSQLが出力されるようにしておくこと。意図した通りのパラメータ化が行われているか、目視で確認する習慣をつけるだけで、事故は激減する。
3. 静的解析ツールの導入:
`Bandit` のようなセキュリティスキャンツールをCI/CDパイプラインに組み込み、`raw()` メソッドの不適切な使用を機械的に弾く環境を構築せよ。
「フレームワークがやってくれるから大丈夫」という慢心は、エンジニアとして最も避けるべき脆弱性だ。
Djangoは強力な武器だが、使う側の知識が伴わなければ、自分自身を傷つける刃物にもなる。技術の裏側で何が起きているのかを常に想像し、泥臭い検証を怠らないこと。それが、真に信頼されるエンジニアへの近道だ。
コメント