All
SaaS管理
デバイス管理
セキュリティ対策
脅威・インシデント対策
IT基盤・インフラ
情シス業務・組織形成
AI / テクノロジー
プロダクト
イベントレポート
その他
ガバナンス

新着記事

もっと見る

>

>

SQLインジェクション(SQL injection)の仕組みと対策|2025年最新の国内被害事例も解説

SQLインジェクション(SQL injection)の仕組みと対策|2025年最新の国内被害事例も解説

SQLインジェクション(SQL injection)の仕組みと対策|2025年最新の国内被害事例も解説

SQLインジェクション(SQL injection)の仕組みと対策|2025年最新の国内被害事例も解説

公開日

近年、SQLインジェクション攻撃の件数が再び増加している。本記事では、攻撃の仕組みから2025年の国内被害事例、現場で今日から実践できる多層防御の具体的な手法までを解説する。

SQLインジェクションの仕組みと、静的プレースホルダを用いた対策や多層防御、国内での被害事例について解説する図。

SQLインジェクションとは

本記事のポイント

  • WAF検出数の6割超:最新のセキュリティレポートによると、Webアプリケーションへの攻撃の半数以上をSQLインジェクションが占めており、依然として最大級の脅威です。

  • AIコーディングやORMの死角:生成AIによるソースコードの検証不足や、オブジェクト関係マッピング(ORM)利用時の生SQLメソッドの誤用により、脆弱性が「再生産」されるケースが多発しています。

  • 根本対策は静的プレースホルダ:エスケープ処理やWAFのみに依存せず、プログラム側で静的プレースホルダ(バインド変数)を徹底することが最善の防御策です。

SQLインジェクション(SQL injection)とは、クロスサイトスクリプティング(XSS)などと並び、Webアプリケーションのセキュリティ脆弱性を利用した代表的なサイバー攻撃の種類です。攻撃者が悪意のあるSQLコードを入力フォームやAPI等のエントリーポイントに挿入し、データベースを不正に操作することで実行されます。グローバルなガイドラインである「OWASP Top 10 2025」においても、インジェクション系攻撃は「A05:2025-Injection」として重要リスクに位置づけられており、現代のWebシステムにおいても最優先で対策すべき脅威であり続けています。

SQLインジェクションの仕組み

SQLインジェクションは、入力フォームやAPI等から悪意あるSQL文を注入しデータベースを不正操作する攻撃である。

Webアプリケーションがユーザーからの入力値をもとに動的にSQL文を組み立てる際、入力値の検証や処理が不適切であると、入力値に含まれる記号(アポストロフィなど)によってSQLの構文が意図せず書き換えられてしまいます。これにより、開発者が想定していなかった「常に真となる条件(例: '1'='1')」などが挿入され、認証をバイパスしてログインされたり、データベース内の情報がすべて奪取されたりします。

この問題を根本的に防ぐのが「静的プレースホルダ(バインド変数)」です。これは、SQLの「構文(命令)」と、そこに流し込む「データ(値)」を明確に分離してデータベースに処理させる仕組みです。あらかじめ命令の骨組みを確定させておくため、データ部分にどのようなSQLコマンドが混入していても、単なる文字列として処理されるため、インジェクション攻撃を完全に無効化できます。

以下は、PHP(PDO)を用いた安全な静的プレースホルダの実装コード例です。

// 【安全な実装例:静的プレースホルダの利用】
$stmt = $db->prepare("SELECT * FROM users WHERE email = :email AND status = 'active'");
$stmt->execute(['email' => $userInputEmail]);
$result = $stmt->fetchAll();

このようにプレースホルダ(:email)に対して値をバインドすることで、データベース側は入力値をただのパラメータとして扱い、SQLの構造を改変されるリスクを排除できます。

動的SQL(脆弱)と静的プレースホルダ(安全)の処理プロセスの違い

▲ 動的SQL(脆弱)と静的プレースホルダ(安全)の処理プロセスの違い

SQLインジェクションの主な種類

SQLインジェクションにはいくつかの主要な種類があり、攻撃者はターゲットとなるシステムの応答挙動やデータベースの仕様に合わせて手口を使い分けます。また、古典的な入力フォームだけでなく、Web APIやHTTPヘッダー、CSV/Excelのインポート機能など、あらゆるエントリーポイントが標的となっています。

攻撃の種類

特徴

主なターゲット・エントリーポイント

ベーシックインジェクション

エラー画面やレスポンスに直接データベースから抽出したデータを出力させる最も古典的な手法。

一般的な検索窓、ID/パスワード入力フォーム

ブラインドインジェクション

画面にエラーやデータが直接表示されない環境で、真偽値(True/False)を返す挙動の違いを利用してデータを推測する。

JSON API、GraphQL、権限判定チェック処理

時間ベースインジェクション

データベースの応答に遅延(SLEEP関数など)を発生させ、そのタイムラグからデータを1文字ずつ特定する。

エラーハンドリングが徹底されたセキュアに見えるシステム、非同期処理API

UNIONベースインジェクション

元のSQLクエリに「UNION」演算子を結合させ、攻撃者が狙う別のテーブルの情報を一括で奪取する。

データの検索・一覧表示機能、CSVダウンロード機能

近年は、モバイルアプリの裏側で動くJSONベースのAPIや、HTTPヘッダー情報(User-AgentやX-Forwarded-For等)をデータベースに保存するログ機能、ユーザーがアップロードするCSVやExcelファイルのインポート処理など、開発者が見落としがちな部分への攻撃シフトが進んでいます。そのため、あらゆる外部入力に対して適切な検証が求められます。

【2025-2026年最新】SQLインジェクションが企業に与える甚大な被害と事例

SQLインジェクション攻撃を受けると、企業は壊滅的な打撃を被る可能性があります。EGセキュアソリューションズが発表した「SiteGuard セキュリティレポート」によれば、国内で検出されたWebサイバー攻撃のうち、実に全体の6割超(約60%〜66%)をSQLインジェクションが占めており、圧倒的な発生割合となっています。また、データ流出による情報漏洩が発生した場合、システムの完全復旧や信頼回復には平均18ヶ月〜24ヶ月を要し、事後対応コストは数千万円から数億円規模に達します。

法的リスクも甚大です。EUのGDPR(一般データ保護規則)では、適切な安全管理措置を怠ったことによる情報漏洩に対し、最大で2000万ユーロ(または全世界売上高の4%)という巨額の制裁金が科される規定があり、グローバルビジネスを行う企業にとって経営を揺るがす財務的負担となります。以下に、日本国内における2025年の最新被害事例を挙げます。

■ 愛知全県模試(2025年発表)

  • 業種・規模:高校生向け模擬試験の運営企業(サービス運営会社含む)

  • 原因:Webサイトの脆弱性を狙ったSQLインジェクション攻撃

  • 被害:受験生や保護者の氏名、生年月日、メールアドレス、パスワードなど、約32万件の個人情報が外部へ流出した可能性が公表されました。

■ 玄海町ふるさと納税特設サイト(2025年発表)

  • 業種・規模:地方自治体(佐賀県玄海町)のふるさと納税特設サイト

  • 原因:システム改修時におけるSQLインジェクション対策(入力検証等)の確認漏れ

  • 被害:納税者など計413,867人分の個人情報(氏名、住所、電話番号、寄付金額等)の漏洩が確定し、自治体の信頼に大きな傷がつきました。

■ 株式会社新興出版社啓林館(2025年発表)

  • 業種・規模:大手教育図書出版企業

  • 原因:学習支援サイト「スマートレクチャー」の質問受付ページにおける脆弱性を突いた攻撃

  • 被害:会員の個人情報の漏洩可能性を公表し、調査期間中はサービスを一時停止しました。

【よくある盲点】開発現場でSQLインジェクションが「再生産」される2つの罠

フレームワークやセキュリティツールが進化した現代においても、開発現場の運用変化によって新たな脆弱性が生まれる「再生産」の罠が存在します。情シスや開発リーダーが注意すべき2つの盲点を解説します。

罠①:「AI生成コード」のレビュー不足によるコピペ・マージ

GitHub CopilotやChatGPTといったAIコーディングアシスタントの普及は開発速度を爆発的に向上させました。しかし、IPAが発表した「情報セキュリティ10大脅威 2026」において「AIの利用をめぐるサイバーリスク」が3位に初選出された背景が示すように、AIは「セキュリティ上安全なコード」よりも「要件通りに動くコード」を優先して提案するケースがあります。AIが提示した「文字列連結(動的SQL)によるSQLインジェクションに脆弱なコード」を、開発者が十分なコードレビューをせずそのままコピペして本番環境にマージし、脆弱性を自ら埋め込んでしまうケースが多発しています。

罠②:「ORMを使用しているから安全」という過信

LaravelのEloquent、TypeScriptのPrisma、Ruby on RailsのActive RecordなどのORM(オブジェクト関係マッピング)を使用していれば、バインド変数が自動適用されるため安全だと誤解されがちです。しかし、複雑な検索クエリや統計処理の実装において、開発者がORMの機能制限を回避するために「生SQLメソッド」(例:Prismaの`$queryRawUnsafe`)を使用し、そこでユーザー入力を文字列連結してしまうミスが頻発しています。

以下に、Prismaにおける危険なコードと安全な書き換えのサンプルを示します。

// ❌ 危険なコード(生SQLメソッドで文字列連結しているため脆弱性あり)
const users = await prisma.$queryRawUnsafe(
  `SELECT * FROM User WHERE email = '${userInputEmail}'`
);

// ⭕ 安全なコード(プレースホルダとテンプレートリテラルを安全に処理するメソッドへ書き換え)
const users = await prisma.$queryRaw`SELECT * FROM User WHERE email = ${userInputEmail}`;

このように、ORMの内部構造や提供されている「Rawクエリ」の安全な呼び出し方を開発チーム全体が正確に把握しておく必要があります。

AI生成コードのレビュー不足によって脆弱性が本番マージされるプロセス

▲ AI生成コードのレビュー不足によって脆弱性が本番マージされるプロセス

SQLインジェクションの正しい対策(多層防御の設計)

SQLインジェクションからシステムを強固に守るためには、最優先すべき根本対策は静的プレースホルダの徹底であり、WAFやサニタイズ(エスケープ処理)は補完的な役割(多層防御の設計)に過ぎないという大原則を理解する必要があります。

Webサーバーへのサイバー攻撃を検知・遮断するWAF(Web Application Firewall)の導入は強力な防衛ラインですが、正規ユーザーの名前(例:O'Connorなどアポストロフィを含む文字列)や住所をSQLインジェクション攻撃と誤認識してブロックする「誤検知(False Positive)」のリスクが常に伴います。そのため、WAF導入時には必ずテスト段階でのシグネチャの調整(チューニング運用)が必要です。また、IPAのガイドラインにもある通り、エスケープ処理は「プレースホルダが仕様上どうしても使えない場合の代替策」に過ぎません。開発・運用フェーズにおけるセキュリティ品質を維持するため、以下のチェックリストおよび自動診断プロセス(SAST/DASTツール)を活用してください。

規模別:開発段階のSQLインジェクション対策チェックリスト

  • 【50名未満の企業・プロジェクト】

    • ✅ 開発時に生SQL(文字列連結)を原則禁止とし、フレームワーク標準のORM(静的プレースホルダ自動適用)のみを使用しているか

    • ✅ Webサーバーの前段に、初期費用を抑えられるクラウド型WAF(Cloudflare等)を即時有効化しているか

  • 【50〜300名規模の企業】

    • ✅ CI/CDパイプラインに「SAST(静的アプリケーションセキュリティテスト)」ツールを組み込み、マージ前にコードの脆弱性を自動検出しているか

    • ✅ リリース前や定期メンテナンス時に、Webアプリケーション脆弱性診断ツール(AeyeScan等)を用いて自動スキャン(DAST)を実行しているか

  • 【300名超のエンタープライズ企業】

    • ✅ 外部のプロフェッショナルによる定期的なペネトレーションテスト(侵入テスト)を年1回以上実施しているか

    • ✅ WAFのログを24時間体制で監視し、新規パッチ適用やシグネチャの最適化運用を専門組織(SOC等)が実施しているか

WAF(外壁)と静的プレースホルダ(根本対策)を組み合わせた多層防御の全体像

▲ WAF(外壁)と静的プレースホルダ(根本対策)を組み合わせた多層防御の全体像

よくある質問

Q:WAFを導入していれば、ソースコードの改修は不要ですか?

A:いいえ、改修は必須です。WAFは攻撃の侵入を防ぐ「外壁」であり、WAF自体の誤検知リスクや巧妙なエンコードによる防御バイパスの可能性があります。根本的な解決策は、あくまでプログラム側で静的プレースホルダを徹底し、脆弱性そのものをなくすことです。

Q:ORMを使用していればSQLインジェクションは100%防げますか?

A:防げません。ORM自体のバグや、開発者が複雑なクエリを書くために「Raw Query(生SQL)メソッド」を呼び出して文字列結合を行うと、通常のSQLインジェクション脆弱性が発生します。ORMの選定だけでなく、生SQLクエリの記述規律や静的解析ツールの導入が必要です。

Q:エスケープ処理(サニタイズ)だけで対策するのはなぜ危険なのですか?

A:データベースの種類や使用している文字コードの組み合わせによっては、エスケープ用の特殊文字処理自体をすり抜ける(バイパスする)攻撃手法が存在するからです。また、開発者がすべての入力箇所でエスケープ処理を漏れなく記述するのは困難なため、静的プレースホルダの利用を原則として義務付ける必要があります。

まとめ

SQLインジェクションは、企業のデータ資産や社会的信頼を根底から破壊する極めて危険な攻撃です。しかし、その根本原因と静的プレースホルダの役割を正しく理解し、開発現場でのコードレビューの徹底やSAST/DASTツールの自動運用、そして適切なWAFチューニングを組み合わせた多層防御を構築すれば、攻撃リスクを大幅に低減できます。明日から取り組める最初の一歩として、まずは現在自社で稼働しているWebアプリケーションのソースコード内に、生SQLの文字列連結(特にAIツールで生成されたコードやORMのRawクエリ)が残っていないか、静的解析ツールや開発チームの緊急棚卸しを実施しましょう。

  • ✅ 自社WebアプリのソースコードでAI生成コードやORMのRawクエリを含む生SQLの文字列連結が使われていないか確認する

  • ✅ CI/CDパイプラインにSASTツールを組み込み、マージ前の脆弱性自動検出を計画・実施する

  • ✅ WAFの導入状況・チューニング状態をセキュリティ担当者と棚卸しし、誤検知の有無を確認する

【監修】本記事は、Webアプリケーションセキュリティおよび情報セキュリティマネジメントの専門知識を持つ編集部が、IPA(独立行政法人情報処理推進機構)・OWASP・EGセキュアソリューションズ等の公開資料をもとに作成・監修しています。

本記事の内容に誤り等がございましたら、こちらからご連絡ください。

監修

Admina Team

情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。