SQLインジェクションとは｜仕組み・主要攻撃4種・実装対策と検知方法

SQLインジェクションとは｜基本の仕組み

SQLインジェクションは、Webアプリがユーザー入力値をクエリ文字列にそのまま連結してしまう実装ミスから発生します。攻撃者は入力欄にクエリ構文として解釈される文字列を仕込み、開発者が想定していないデータ操作を引き起こします。

SQLとはというデータベース操作言語の構文を、アプリ側がエスケープせずそのままサーバへ渡してしまうのが本質です。

なぜ今も発生し続けるのか

OWASP Top 10:2025 でも、Injectionカテゴリ（SQL／NoSQL／コマンド／LDAP等）は主要リスクとして引き続き扱われています。フレームワーク側でパラメータ化クエリが既定になり、認知も進んできましたが、報告は絶えません。理由は3つあります。

第1に、レガシーアプリの保守案件に古い文字列連結コードが残っていること。第2に、新規開発でも動的に組み立てたい場面（検索条件のソート列指定など）で、つい素のSQLを組んでしまうこと。第3に、フレームワーク経由でも生クエリ実行関数を呼べば防御は効かないことです。

IPAの脆弱性対策情報 でも、SQLインジェクションは代表的な脆弱性として継続的に注意喚起の対象になっています。届出件数の年次推移はIPAの公開資料で確認できます。

攻撃の流れ

実際の攻撃は、次のような段階で進みます。

1. 入力欄にクォート記号を入れて、エラー応答や挙動の違いを観察する

2. クエリ構文として解釈されると判明すれば、論理演算で常に真になる条件式を埋め込む

3. ログイン画面なら認証回避、検索画面なら他テーブルの情報取得を試みる

4. 成功した手口を自動化ツールでなぞり、大量データを抽出する

入力エラーが画面に出ない設計でも、応答時間や応答長の差で攻撃可否を判定する手口があります（次章のブラインド型）。

現場で多い誤解：ORM経由なら絶対安全？

ORMでも、生クエリ実行関数や、列名・テーブル名を変数に持たせる箇所は対策外です。「ORM＝安全」と思い込むのが一番危険です。

主要な攻撃パターン4種

攻撃は応答の取り方で4種類に整理できます。コードレビューや診断レポートを読む際の基本語彙です。

クラシック型（インバンド／Union型）

最も古典的な手口で、攻撃者は同じ画面の応答から直接データを取得します。検索結果欄やエラーメッセージに、本来は表示されないテーブルの情報が露出するのが特徴です。

ブラインド型

応答にデータ自体は出ないものの、真偽による画面の差で情報を抜き出します。「正常ページが返る／エラーが返る」「商品が見つかる／見つからない」といった差分を一文字ずつ確認していく地道な攻撃です。

タイムベース型

応答に差が出ない場合でも、応答が遅延するかどうかで判定する手口です。データベース側に遅延処理を仕込ませ、応答秒数で1ビットずつ情報を読み取ります。検知の難易度が高く、APIエンドポイントで気付かれないことがあります。

帯域外型（OOB）

被害サーバから攻撃者の外部サーバへDNSやHTTPで直接データを送らせる手口です。アプリの応答を見ずに済むため、レスポンスを返さない非同期APIや、画像変換などのバックグラウンドジョブを狙われます。

現場で多い誤解：自動診断ツールで全パターン見つかる？

タイムベース型と帯域外型は、画面上の異常が出ないため、コードレビューでも診断ツールでも見落とされやすいパターンです。ブラックボックス診断だけに頼らず、コード側のクエリ生成箇所を必ず点検します。

国内外の被害事例

事例は氷山の一角ですが、典型パターンを掴むのに役立ちます。

教育サービスでの大規模流出

2025年4月には、教育関連サイトを巡って、SQLインジェクションが原因の可能性があるとして大規模な情報流出が報じられた事例があります。報道ベースでは受験者・関係者の個人情報が外部に流出した可能性が指摘され、入力値の取り扱いとクエリ生成の不備が原因として論じられています（SHIFT「SQLインジェクションとは」 の解説記事で経緯が整理されています。正確な件数・原因の最終確定状況は被害企業の公表資料・公的報道を参照してください）。

医療・公共領域でのDB改ざん

医療系の情報サイトで、データベースの内容が書き換えられた事例も継続的に報告されています。公共領域の改ざんは、誤情報拡散による二次被害につながりやすく、復旧にも時間がかかります。

EC・SaaSでの永続的なリスク

会員制ECサイトや業務SaaSは、攻撃価値が高く、認証情報・購買履歴・取引データを抱えています。これらが流出すると、被害企業のサービス停止だけでなく、取引先のサプライチェーン全体に影響が及びます。フリーランスとして参画する案件でも、扱うデータの機密度を把握しておく姿勢が必要です。

発覚経路の傾向

公開された侵害事例の多くは、外部研究者・利用者・取引先からの指摘で発覚しています。社内ログだけでは異常を見抜けず、外部の脆弱性報奨金や脆弱性届出（IPA経由）で発見されるケースが目立ちます。

開発現場での検知方法

検知は「コード」「テスト」「運用」の3層で行います。

コードレビューで見るべき箇所

• 文字列連結で組み立てているクエリ生成箇所

• ORMの 生クエリ実行関数を呼び出している箇所

• 列名・テーブル名・並び替え方向を変数で受け取っている箇所

• 検索画面のソート指定・絞り込み条件の動的生成

• 古いコードに残る、自前のエスケープ関数

レビュー時は「ユーザー入力 → クエリ文字列 までの経路」を辿り、プレースホルダで受けていない値を探します。

動的テスト・SAST/DASTツール

• SAST（静的解析）：ソースを走査して危険箇所をリストアップ

• DAST（動的解析）：実際にリクエストを送って応答を観察

• IAST：アプリ内部の挙動を計測しながら検知

無料ではOWASP ZAPやsqlmapが使われます。商用ではBurp Suite Professionalや、各クラウドのマネージド診断サービスが定番です。フリーランス案件で「脆弱性診断」と書かれている工程は、おおむねこれらのツールの実行とレポート読解を含みます。

運用ログ・WAFログでの兆候

WAFや負荷分散装置のログには、遮断したリクエストのペイロードが残ります。クォート・コメント記号・論理式の出現頻度を集計し、平常時のベースラインと比較するのが基本です。誤検知も多いため、実際のテーブル名やカラム名を含むリクエストを優先的に確認します。

現場で多い誤解：自動診断ツールに頼り切ってよい？

ツールはクラシック型の発見が得意ですが、ブラインド型・タイムベース型・OOB型は条件設定とログ解釈が必要です。ツール結果を見たうえで、コード側の生成箇所を1次レビューするのが安全です。

コード対策の基本

IPA「安全なウェブサイトの作り方」 が示す根本対策は明確です。

根本対策：プリペアドステートメント（パラメータ化クエリ）

クエリの構文部分と値の部分を分離してサーバに送る方式です。値は文字や数値として扱われるため、クォートや論理演算記号が含まれても構文として解釈されません。値の埋め込みに起因するSQLインジェクションを大幅に防ぎやすく、最も推奨される対策です。IPAの「安全なウェブサイトの作り方」では、この方式の中でも「静的プレースホルダ」と呼ばれる実装を原則として推奨しています。

なお、列名・テーブル名・ソート方向のようなクエリ構造の動的な切り替えはバインドだけでは守れません。次節の保険的対策と組み合わせます。

保険的対策（多層防御の補強）

• ユーザー入力の型・長さ・形式の検証（例：数値項目に数字以外を拒否）

• データベース接続ユーザーの最小権限化（読み取り専用、特定テーブルのみ等）

• アプリのエラーメッセージでSQL構文・テーブル名を返さない

• 不要な機能の無効化、デフォルト管理アカウントの削除

これらは根本対策の代替ではなく、防御層を厚くするためのものです。「WAFを入れたから対策完了」とは見なされません。

やってはいけない実装

• 自前の文字列エスケープ関数で済ませる

• ブラックリスト方式で危険語をフィルタする

• 列名・並び順を文字列連結で組み立てる

• 入力欄ごとに対策有無がばらつく

ブラックリスト方式は、新しい攻撃ベクトルに即座に追随できないため、根本対策にはなりません。

動的プレースホルダと静的プレースホルダの違い

IPA文脈では、サーバ側でクエリと値を分離する「静的プレースホルダ」が原則として推奨されます。「動的プレースホルダ」は実装方式によってアプリ側またはドライバ側の処理に依存するため、静的方式に比べて注意点が増えます。フレームワークやドライバが静的方式を選べる場合は、まず静的方式を選択します。

フレームワーク別の対策ポイント

主要フレームワークは安全な書き方を既定で用意しています。落とし穴は「便利だから」と素のクエリを呼ぶ箇所です。

PHP / Laravel

クエリビルダやEloquent ORM経由なら、値はバインドされてサーバへ渡ります。注意は DB::raw や生のクエリ実行関数を呼ぶ場面です。検索条件のカラム指定、並び替え方向、IN句の値リストなどで安易にraw関数を使うと、入口を作ってしまいます。

Ruby on Rails

Active RecordはハッシュやArel経由でバインド方式に乗りますが、文字列フラグメントを検索条件に直接渡す書き方で穴が空きます。ソート列の名前を文字列で受け取って組み立てる箇所は危険になりやすく、列名はホワイトリスト方式で受けるのが定石です。

Django / Python

Django ORMはパラメータ化を既定とします。要注意は raw メソッドと extra メソッドで、これらは生クエリを扱うため、自前で安全性を担保する必要があります。値そのものは ORM 経由でバインドできても、SQL関数名やテーブル名の動的指定は別途設計します。

Node.js / Express

mysql2 や pg などの主要ドライバはプレースホルダ機能を備えています。注意点は、テンプレートリテラルでクエリ文字列を組んでしまい、プレースホルダを使い忘れることです。TypeORM / Prisma / Drizzle のような ORM 利用時も、生クエリ関数の入力には同じ配慮が必要です。

実務での現実解

ORMだけで案件の指摘がゼロになることはまずありません。複雑な検索画面や帳票出力では、動的に組み立てたい列・テーブルが必ず出てきます。診断レポートでも、生クエリの混在を指摘されるケースが多い印象です。「ORMで書く＋例外は最小化＋例外箇所はホワイトリスト」が現実的な落とし所です。

運用・インフラ側の対策

コード対策が根本だとしても、運用層での備えは攻撃面を狭めます。

WAF（Web Application Firewall）の役割

WAFは、攻撃パターンに一致するリクエストを手前で遮断します。ゼロデイ対策や、レガシーアプリの保守案件でコード修正が即時にできない期間の保険として有効です。クラウド型WAF（Cloudflare のWAF機能、AWS WAF、Akamai等）が一般的になっています。

ただし、WAFはコード側の脆弱性そのものを修正しません。誤検知・回避手口もあるため、根本対策と並行運用するのが原則です。

最小権限の原則

アプリがDBへ接続するユーザーには、必要最低限の権限だけを付与します。

• 参照系APIは読み取り専用ユーザーで接続

• 管理系処理だけ、書き込み権限のあるユーザーを使う

• スキーマ変更権限はアプリから付与しない（マイグレーション専用ロールに分離）

被害が発生しても、書き換え・削除まで進ませないための防壁です。

エラー応答の制御

本番環境では、データベースの詳細エラーメッセージを応答に含めない設定にします。テーブル名・カラム名・SQL構文断片が画面やAPI応答に出ると、攻撃者の偵察コストを大きく下げてしまいます。

ログ・監視

• アプリの異常クエリ件数

• WAFの遮断件数とパターン

• DBの異常な大量参照（普段読まないテーブルへのアクセス）

• 認証失敗の連続発生

監視は、平常時のベースラインを取った上で異常検知ルールを引きます。

WAFのデフォルトルールセットだけで十分か

既定ルールは汎用的な攻撃を弾きますが、アプリ固有のパス・パラメータには適合していません。最初の数週間はログ観察モードで誤検知を確認し、本アプリ向けに調整するのが定石です。

ケース別｜担当領域ごとの実装ポイント

フリーランス案件では役割によって関わり方が変わります。

バックエンド開発者として参画する場合

• すべてのクエリ生成箇所でプレースホルダ方式を統一する

• レビュー時に「動的に変えたいのは値か、構造か」を必ず確認する

• 既存コードの保守案件では、先に診断を入れて優先度をつけてから修正に取り掛かる

バックエンドエンジニア として参画する場合、APIエンドポイントごとに入力検証・クエリ生成・エラー応答の3点をセットで設計します。

フロントエンド担当でも知っておくべきこと

クライアント側だけでバリデーションを完結させても、サーバ側で検証していなければ意味がありません。APIに何を送っているか、開発者ツールで確認しながら、サーバ側の責任分界を理解しておくと、コードレビューでも有用です。

データベースエンジニアとして関わる場合

接続ユーザーの権限設計、監査ログ、スロークエリ監視がメイン領域です。データベースエンジニア や MySQL・PostgreSQL の案件では、アプリ側で起こったインジェクションをDB側でどう封じ込めるかの設計が問われます。

セキュリティ専門として関わる場合

セキュリティエンジニア として、診断レポートの作成・改修方針の提示・WAFチューニングが業務範囲です。報告書では、根本対策と保険的対策を分け、修正期日と優先度を明示する書き方が求められます。

公共系・大規模案件で求められる対策

官公庁・公共系の案件 では、IPA「安全なウェブサイトの作り方」準拠が調達仕様書で求められることが多く、納品時の脆弱性診断・第三者確認も要件化されます。一般案件以上に、対策の根拠と試験結果を文書化しておく姿勢が大切です。

中小規模アプリでのWAF判断

WAFは保険的対策で、規模より扱うデータの機密度で判断します。個人情報・決済情報・認証情報を扱うなら、規模が小さくても導入する価値が高くなります。クラウド型WAFは小規模でも月数千円台で導入できるケースがあります。

フリーランス案件における関係性

「SQLインジェクション対策」がそのまま案件名になることは少ないものの、関連業務は多くの案件に組み込まれています。

案件タイプと求められる経験

関連資格と学習リソース

実務経験を伴った情報セキュリティマネジメント試験 や、より上位の情報処理安全確保支援士（登録セキスペ）は、公共系・金融系案件のスキル証明として参照されることがあります。資格単体で単価が決まるわけではありませんが、応募時の足切り回避やスキルの裏付けとして一定の意味があります。

単価の傾向

セキュリティ専門のフリーランス案件は、開発系案件より単価レンジが上振れする傾向があります。例えばレバテックフリーランスの脆弱性診断 求人・案件 ページなど、フリーランスエージェントの公開案件ベースでは、本記事執筆時点で月額70万〜120万円台の募集例が一定数見られます（母集団は各社の掲載公開案件、掲載時点の数値です）。実際の単価は実務経験・診断レポート実績・対象システム規模で大きく振れるため、各社の公開単価はあくまで参考値として捉えるのが安全です。

診断経験がない場合のキャリア入口

開発経験はあるが診断経験はない場合でも、入口はあります。開発側のセキュアコーディング案件、診断アシスタント、脆弱性管理ツール運用などが現実的です。手動診断のメイン担当に上がるには、社内案件や副業で診断経験を積むか、関連資格・脆弱性報奨金プラットフォームでの実績作りが近道になります。

実践チェックリスト

レビューや診断準備で使える、自己点検用のチェックリストです。

コード側

• ☐

  すべてのクエリでプレースホルダ方式を使っているか

• ☐

  ORM経由でも生クエリ実行関数を使っていないか

• ☐

  列名・テーブル名・並び順をホワイトリストで受けているか

• ☐

  エラー応答にSQL構文・テーブル名・カラム名が含まれていないか

• ☐

  入力値の 型・長さ・形式を検証しているか

設計・運用側

• ☐

  DB接続ユーザーが最小権限になっているか

• ☐

  本番ログに異常クエリの検知ルールを設定しているか

• ☐

  WAFをログ観察モードで確認したうえで有効化しているか

• ☐

  スキーマ変更権限がアプリ側ユーザーから分離されているか

• ☐

  脆弱性診断を定期的に実施しているか（年次・リリース時）

案件参画時

• ☐

  担当領域の入力経路がドキュメント化されているか

• ☐

  既存の診断レポートや指摘事項が共有されているか

• ☐

  修正の優先度判断基準（被害想定・影響範囲）が決まっているか

• ☐

  WAFのチューニング担当が明確か

まとめ

SQLインジェクションは、ユーザー入力をクエリ構文として解釈させてしまう設計ミスから発生し、対策はプレースホルダによるクエリと値の分離を根本に据えるのが現代の正解です。WAFや最小権限は保険的対策として組み合わせ、コード・設計・運用を多層で守ります。

要点を整理します。

• 攻撃4種（クラシック／ブラインド／タイムベース／帯域外）の見分けと、検知の難易度を把握する

• 根本対策は静的プレースホルダ。自前エスケープ・ブラックリストには頼らない

• 主要フレームワークでも生クエリ実行関数と列名の動的指定は要警戒

• WAF・最小権限・エラー隠蔽・監視を組み合わせて多層防御を作る

• フリーランス案件ではコードレビュー・診断・WAFチューニング・レポート作成が関連業務として頻出

次のアクションとしては、自分が関わるプロジェクトのクエリ生成箇所の棚卸しから始めるのがおすすめです。意外と「素のSQL」が残っている箇所が見つかります。

参照元・一次情報リンク：

• IPA「安全なウェブサイトの作り方」1.1 SQLインジェクション

• IPA 脆弱性対策情報｜SQLインジェクション

• OWASP Top 10:2025（Injection）

• SHIFT「SQLインジェクションとは｜手口・被害事例・対策」

• レバテックフリーランス 脆弱性診断 求人・案件

セキュリティ領域の案件・キャリアに関心がある方は、フリコンのフリーランスエージェントサービスを通じて、適性に合う案件の相談が可能です。