「Djangoなら絶対安全」という思い込みが危ない！ORMとSQLインジェクションの真実
こんにちは。現場で泥臭いインシデント対応をしていると、「フレームワークを使っているからセキュリティ対策は万全だよね？」という声をよく耳にします。確かにDjangoのような優れたフレームワークは、多くの「罠」を自動で避けてくれる頼もしい相棒です。
でも、家の鍵をどれだけ頑丈にしても、窓を開けっ放しにしていたら泥棒は入ってきますよね？今回は、Djangoがどうやってデータベースを守っているのか、そして、どんな時にその守りが「無効化」されてしまうのか。身近な例えを交えて紐解いていきましょう。
—
1. Django ORMという「自動鍵かけシステム」
Django ORM（Object-Relational Mapping）を使うと、SQLという難しい言語を直接書かなくても、Pythonのコードだけでデータベースを操作できますよね。
実は、Django ORMは「自動鍵かけシステム」のようなものです。あなたが`User.objects.filter(username=input_name)`と書くと、Djangoは裏側で以下のような処理をしてくれています。
- 「入力された文字をそのままクエリに埋め込む」のではなく、「値の枠（プレースホルダ）」だけを用意する。
- 入力値は「あくまでデータである」とデータベース側に伝える。
これは、郵便受けから手紙を入れるときに、中身がどんなに怪しいものでも「中身はただの紙」として扱い、家の構造（データベースの命令）を破壊させない仕組みです。これを「バインド変数（パラメータ化）」と呼びます。これのおかげで、攻撃者が`’ OR ‘1’=’1`のような悪意ある命令を紛れ込ませても、ただの「ユーザー名」として処理され、家の中（データベース）に侵入されることはありません。
—
2. なぜ「生SQL」を使うと泥棒が入るのか？
しかし、開発現場では「複雑な集計が必要だから」といった理由で、どうしても生のSQLを書かなければならない場面が出てきます。ここで登場するのが `raw()` メソッドです。
もし、あなたが以下のようなコードを書いてしまったら、それは「頑丈な玄関ドアの横に、合鍵をぶら下げている」のと同じ状態です。
危険なコードの例（絶対にやっちゃダメ！）
悪い例：f文字列でSQLを組み立てている
user_input = “‘ OR ‘1’=’1″ # 攻撃者が入力した想定
query = f”SELECT FROM myapp_user WHERE username = ‘{user_input}'”
これを実行すると、データベースは「全員の情報を出せ」と命令されたと勘違いします！
User.objects.raw(query)
このコードでは、Pythonの文字列としてSQLを組み立ててしまっています。これだと、Djangoの「自動鍵かけシステム」が機能する前に、SQLが完成してデータベースに送られてしまいます。これこそがSQLインジェクションのメカニズムです。
—
3. 「生SQL」でも安全に戦うための鉄則
「じゃあ、複雑なSQLは諦めるしかないの？」と不安になる必要はありません。Djangoには、生SQLを書くときでも鍵をかける仕組みがちゃんと用意されています。
安全なコードの例
良い例：パラメータ化（バインド変数）を使う
user_input = “‘ OR ‘1’=’1”
プレースホルダ（%s）を使って、値を分離する
query = “SELECT FROM myapp_user WHERE username = %s”
パラメータをリストとして渡す。これならDjangoが安全に処理してくれます
User.objects.raw(query, [user_input])
この方法であれば、たとえ `user_input` に危険な命令が含まれていても、データベースはそれを「usernameという列を探すための単なる値」として認識します。命令（SQL）とデータ（入力値）を厳格に切り離すこと、これがセキュリティの基本中の基本です。
—
4. 今日からできる「守りの意識」
新人エンジニアの皆さんに、現場の先輩として一つだけアドバイスがあります。
「フレームワークの便利機能は、魔法ではなく『仕組み』である」と理解してください。
- なるべくORMを使う： ほとんどの処理はORMで完結します。生SQLが必要なのは本当に特殊なケースだけです。
- 生SQLを使うなら「％s」を信じる： 文字列連結（`f”{var}”` や `+`）でSQLを作らない。これは鉄の掟です。
- 入力値は常に「怪しいもの」と疑う： ユーザーから送られてくるデータは、家の前に置かれた不審な荷物だと思って接してください。
セキュリティは、一度設定して終わりではありません。日々のコードレビューで「このSQLの書き方、少し危なくない？」と声を掛け合う、そんなチームの雰囲気が、どんな高価なセキュリティツールよりも強い盾になります。
一歩ずつ、着実に学んでいきましょう。あなたの書くコードが、誰かの大切な情報を守る防壁になります。応援していますよ！
コメント