SQLインジェクションとは？仕組みと情シスの対策を解説

SQLインジェクションとは？仕組みと情シスの対策 用語解説

SQLインジェクションとは、Webアプリケーションの入力値を通じてデータベースへの命令文（SQL文）を改ざんされ、情報の窃取・改ざん・認証回避などを許してしまう脆弱性です。20年以上前から知られている「枯れた」攻撃でありながら、いまだに大規模な情報漏えいの原因であり続けています。

厄介なのは、情シスの多くが自分でSQLを書かないことです。攻撃の入口は自社開発のシステムだけでなく、調達したパッケージ製品、委託先が作ったWebサイト、業務で使っているSaaSにも潜んでいます。「うちは開発部門じゃないから関係ない」とは言えないのが実情です。

この記事でわかること

  • SQLインジェクションの仕組みと、なぜ今も攻撃が成立するのか
  • IPAが示す「根本的解決」と「保険的対策」の違い
  • 自分でコードを書かない情シスが、調達・委託先管理・運用でやるべきこと
  • WAFで守れる範囲と、守れない範囲

SQLインジェクションとは何か

Webアプリケーションは、利用者が入力した値（ID、検索キーワードなど）を組み込んでSQL文を作り、データベースに問い合わせます。このとき、入力値を単純に文字列としてつなぎ合わせてSQL文を組み立てていると、入力値の中に「SQL文の一部として解釈される文字」を紛れ込ませることで、開発者が意図しない命令に書き換えられてしまいます。これがSQLインジェクション（SQL注入）です。

たとえばログイン画面で、利用者が入力したIDとパスワードをそのままSQL文に埋め込んでいる場合を考えてみます。攻撃者がパスワード欄に「常に真になる条件」を意味する文字列を入れると、認証条件そのものが無効化され、パスワードを知らないままログインできてしまうことがあります。攻撃者はプログラムを壊しているのではなく、アプリケーションが用意した入力欄を、設計どおりに使いながら別の意味を持たせているのがポイントです。

どんな被害が起きるのか

IPA「安全なウェブサイトの作り方」は、SQLインジェクションによって発生しうる脅威として次の4つを挙げています。

脅威 現実に起きること
非公開情報の閲覧 顧客情報・個人情報がデータベースごと引き抜かれる
情報の改ざん・消去 データの書き換え、テーブルの削除
認証回避による不正ログイン 他人になりすまし、その権限で操作される
ストアドプロシージャ等を悪用したOSコマンド実行 データベースを踏み台にサーバ自体を掌握される

最後の1行が特に重要です。SQLインジェクションは「データが漏れる」だけの話に見えがちですが、条件が揃えばサーバ上でのコマンド実行にまで発展し、そこから権限昇格や内部ネットワークへの侵入へとつながります。入口がWebフォーム1つでも、着地点は社内システム全体になりうるということです。

なぜ今も無くならないのか

対策方法が確立して久しいにもかかわらず、SQLインジェクションは統計上もはっきり残り続けています。IPAが公表したJVN iPedia 2026年第1四半期（1月〜3月）の登録状況では、登録された脆弱性11,605件のうち、CWE-89（SQLインジェクション）は393件で第4位でした。上位はCWE-79（クロスサイトスクリプティング）1,163件、CWE-74（インジェクション）406件、CWE-22（パス・トラバーサル）402件と続きます。四半期あたり数百件が新たに登録されている、というのが現在地です。

一方、OWASP Top 10:2025 では、インジェクションは A05（5位）と、2021年版のA03（3位）から順位を下げました。フレームワークの普及で「新しく作るシステム」では作り込みにくくなってきた、という背景があります。ただしOWASPはCWE-89について、発生頻度は下がっても影響が大きい類型（low frequency / high impact）として扱っており、CVEは累計14,000件を超えています。「減ってきたが、当たると重い」——これが実務での位置づけとして正確な理解です。

そして残るのは、たいてい古いシステムです。10年前に作られ、開発した会社ともう付き合いがなく、ドキュメントも残っていない業務システム。新規開発の統計が良くなっても、社内に居座り続けるそうしたシステムのリスクは自動的には減りません。

対策の考え方：根本的解決と保険的対策

IPAは対策を「根本的解決」と「保険的対策」に明確に分けています。この区別を押さえておくと、ベンダーとの会話がぶれません。

根本的解決＝プレースホルダを使う

SQL文の組み立ては、すべてプレースホルダで実装する。これがIPAの示す根本的解決です。プレースホルダとは、SQL文の雛形に「ここに値が入る」という目印を置いておき、実際の値を後から機械的に割り当てる仕組みのことです。値がSQL文の構造として解釈される余地がなくなるため、脆弱性の原因そのものが消えます。

プレースホルダには2方式あります。

  • 静的プレースホルダ：SQL文の構造を先にデータベース側でコンパイルし、値はデータベースエンジンが割り当てる方式。原理的にSQLインジェクションが成立しないため、IPAもこちらが優るとしています。
  • 動的プレースホルダ：アプリ側のライブラリが値をエスケープしてから埋め込む方式。脆弱性は解消できますが、安全性はライブラリの実装に依存します。

文字列連結でSQL文を組み立てる実装が残っている場合は、エスケープ処理（シングルクォートの二重化など）が必須になりますが、これはすべてのリテラル生成に漏れなく適用して初めて意味があるもので、人手に依存する分だけ脆いやり方です。移行できるならプレースホルダに寄せるのが筋です。

保険的対策＝被害を小さくする

根本的解決を「してある」前提でも、万一に備える対策としてIPAは次を挙げています。

  • エラーメッセージをそのままブラウザに表示しない：DBの種類やSQL文の構造が攻撃者に伝わり、攻撃の精度を上げる材料になります。
  • データベースアカウントに適切な権限を与える：アプリが使うDBアカウントに不要な管理者権限を与えない。最小権限の原則そのものです。SELECTしかしない画面のアカウントにDROP権限が付いていれば、1件の脆弱性が全消去に化けます。

名前のとおり保険であって、これらをやってもSQLインジェクションは防げません。「WAFを入れたので対策済みです」という説明が出てきたら、根本的解決の話にすり替わっていないか確認してください。

WAFはどこまで守ってくれるのか

WAF（Web Application Firewall）は、SQLインジェクションらしい攻撃パターンを含む通信を検知・遮断します。すぐに直せない既存システムを抱えている情シスにとっては、現実的で有効な打ち手です。

ただしWAFは入口で怪しい通信を止めているだけで、アプリの中にある欠陥は残ったままです。攻撃者はエンコードを変える、分割して送るなど、パターンマッチをすり抜ける工夫を重ねてきます。WAFの正しい位置づけは「修正までの時間を稼ぐ盾」であって、恒久対策ではありません。導入したなら、いつまでに何を直すのかという期限をセットで持つべきです。

情シスの実務でどう扱うか

ここが本題です。コードを書かない情シスにとって、SQLインジェクション対策は実装の話ではなく、調達と委託先管理と棚卸しの話になります。

1. Webシステムの棚卸しをする

まず「社外からアクセスできて、データベースにつながっているもの」を洗い出します。採用サイト、問い合わせフォーム、イベント申込ページ、部門が独自に立てた小さなWebアプリ——情シスが把握していないものほど危ないのが常です。正直なところ、この棚卸しが一番つらい工程で、かつ一番効きます。攻撃者は組織図を見て攻めてきてはくれません。

2. 発注仕様に「準拠すべき基準」を書く

新規開発・改修を外部に頼むときは、IPA「安全なウェブサイトの作り方」（改訂第7版）に準拠することを仕様書や契約に明記します。「セキュリティに配慮すること」という一文では、何も担保できません。SQLに関しては「SQL文の組み立てはすべて静的プレースホルダで実装する」と具体的に書けるかどうかで、受け入れ検査の質が変わります。

3. 脆弱性診断を「納品条件」にする

リリース前の脆弱性診断を検収条件に組み込み、検出された指摘の是正までを納品範囲に含めます。改修のたびに新たな画面が増えるので、一度きりではなく改修時にも実施する取り決めにしておくのが実務的です。

4. 古いシステムには期限を切る

棚卸しで出てくる「作った会社がもういない」システムは、直せないことが多い。ここで現実的な選択肢は、外部公開をやめる／アクセス元を絞る／WAFで暫定的に守りつつ更改計画を立てる、のいずれかです。放置だけは選択肢に入れない、という線引きを経営層と共有しておくことが情シスの仕事になります。

なお、SQLインジェクションの脆弱性が製品側に見つかった場合は、CVEとして識別子が振られ、深刻度がCVSSで評価されます。自社が使っている製品の情報をJVN／JVN iPediaで追う運用も、あわせて回しておきたいところです。

参考にすべき公的資料

対策の詳細は、自前でチェックリストを作るより公的資料を正面から使うのが確実です。

あわせて、開発を依頼する側・受け入れる側の担当者が「プレースホルダとエスケープの違い」を説明できる状態にしておくことも、地味ですが効きます。技術的な最終防衛線を張るのは開発者ですが、それを要求として突きつけられるのは情シスだけです。

まとめ

  1. SQLインジェクションは、入力値でSQL文を改ざんされる脆弱性。情報漏えいだけでなく、認証回避やOSコマンド実行を経てサーバ掌握にまで至りうる。
  2. 根本的解決はプレースホルダ（静的方式が優る）。エラーメッセージの非表示やDBアカウントの最小権限は「保険的対策」であり、WAFも含めて恒久対策の代わりにはならない。
  3. 情シスの主戦場は調達・委託先管理・棚卸し。発注仕様にIPAの指針への準拠を明記し、脆弱性診断を納品条件にし、直せない古いシステムには期限か遮断かの判断を下す。

出典

タイトルとURLをコピーしました