SQLインジェクションは、入力された値を悪用して、データベースへの命令を不正に変える攻撃です。本来は検索する言葉などとして扱う入力が、命令の一部として解釈されることで起こります。
ニュースで「SQLインジェクションにより情報が流出」と聞くと、難しい操作で奥へ侵入したように感じるかもしれません。入口は、サイトが普段から受け付けている検索やログインなどの入力になる場合があります。
ただし、入力欄があるだけで危険なのではありません。受け取った情報から、どのように命令を組み立てるかが問題になります。
SQLインジェクションとは入力と命令の区別が崩れること
最初に、名前に出てくる二つの言葉を整理します。
| 言葉 | 何をするものか | 身近な例 |
|---|---|---|
| データベース | 情報を整理し、必要なものを探したり更新したりする仕組み | 商品情報や注文履歴を保存する |
| SQL（エスキューエル） | データベースへ検索や更新などを指示するための言語 | 指定した商品に合う情報を取り出す |
インジェクションは「注入」という意味です。SQLインジェクションでは、データとして受け取るはずの場所から、命令を変えるための内容が入り込みます。
検索したい言葉が、別の指示になってしまう
たとえば、商品検索に「青いマグカップ」と入力するとします。サイト側は、その言葉に合う商品をデータベースから探し、結果を返します。このとき「青いマグカップ」は、探す対象を指定する値です。
ところが、入力された文字をそのまま命令文へつなぐ作り方では、特別な意味を持つ文字などによって、命令の条件が変わる場合があります。攻撃者はその不備を狙い、本来とは違う情報を取り出させるなどの操作を試みます。
これは仕組みを説明するための例です。ここに挙げた商品名が攻撃になるわけではありません。入力内容を「調べる対象」として扱うはずが、「何をするかの指示」に混ざることが問題です。
JPNICのSQLインジェクション解説も、アプリケーションの入力を通じて、データベースへ不正な操作を加える攻撃として説明しています。SQL自体が危険な言語という意味ではありません。
SQLインジェクションで情報漏えいが起きる理由
サイトは、利用者に必要な情報だけを表示するために、データベースへ問い合わせます。その問い合わせを不正に変えられると、見せる予定のない情報まで取り出される可能性があります。
また、影響は読み取りだけとは限りません。データを書き換える、消す、ログインの確認を回避するといった被害につながる場合もあります。IPAのSQLインジェクション対策では、こうした脅威と対策が整理されています。
| 不正に行われ得ること | 生活で困ることの例 |
|---|---|
| 非公開の情報を読む | 登録情報や注文情報などが外部へ渡る |
| 保存情報を書き換える | サイトの表示や登録内容が変わる |
| 情報を消す | サービスの提供や復旧に支障が出る |
| ログインの確認を回避する | 本人に許された機能を他人が使う |
どこまで可能かは、サイトの不備、保存している情報、データベースへ与えた権限などで変わります。一度の攻撃で必ずすべての情報や機能が奪われる、という表ではありません。
HTTPSでもSQLインジェクションは起こる？
HTTPSは、ブラウザとサイトの間の通信を保護する仕組みです。一方、SQLインジェクションは、受け取った内容をサイトの中でどう処理するかの問題です。
通信が保護されていても、届いた内容を扱うプログラムに不備があれば、問題は残ります。HTTPSで開けることは大切ですが、それだけでサイト内部の安全性まで確認できるわけではありません。
これは、利用者が怪しいリンクを押したから必ず起きる攻撃でもありません。サイト側が受けた攻撃で、そこへ情報を預けていた利用者が影響を受ける場合があります。
SQLインジェクション対策はサイト側で何を分ける？
対策の中心は、データベースへ行わせる命令の形と、利用者が入力した値を分けて扱うことです。入力された値が、勝手に新しい命令の一部へ変わらないようにします。
どの情報を、どんな条件で探すかを用意する
入力された商品名などを、値として受け取る
入力値が、別の命令を作る材料にならないように扱う
対策の考え方を示す模式図です。具体的な実装は、使う言語・データベース・機能に合わせて確認します。
開発の説明では、プリペアドステートメントやプレースホルダという言葉が出てきます。まずは、次のように役割で捉えると分かりやすくなります。
- プリペアドステートメント：命令の形を用意し、値を別に渡して使う仕組み。
- プレースホルダ：その命令の中で、後から値を入れる場所を示すもの。
具体的な使い方は、言語やデータベースで異なります。名前のある機能を一か所に使えば、サイト全体が安全になるという意味ではありません。入力を使って命令を作る箇所を、適切に扱う必要があります。
怪しい文字を削れば、それだけで防げる？
「危なそうな文字を見つけて消す」だけに頼ると、想定していない書き方を見逃すおそれがあります。入力が想定した種類かを確かめることに加えて、命令と値を安全に分ける仕組みを使います。
さらに、サイトがデータベースに対してできる操作を、必要な範囲へ絞ることも大切です。読むだけでよい機能へ、不要な変更や削除の権限まで渡さないようにすれば、問題が起きた際の影響を抑える助けになります。
こうした修正は、主にサイトを開発・運用する側が担います。利用者が自分のパスワードを長くすることとは、別の対策です。
SQLインジェクションのニュースを見た利用者が確認すること
利用者が画面を見ただけで、サイトのSQL処理に問題がないか判断するのは困難です。確かめるために、知らないサイトの入力欄へ攻撃用の文字列を試す必要もありません。
使っているサービスで問題が公表されたときは、公式のお知らせで次を確認します。
- 対象は誰か：利用時期やサービス、対象者の条件を見る。
- どの情報か：名前、連絡先、パスワードなど、確認された範囲を分ける。
- 何を求められているか：公式の再設定案内や相談先を確認する。
情報漏えいの原因がSQLインジェクションでも、利用者の対応は、実際に影響した情報によって変わります。「この攻撃名なら全員が同じ操作をする」とは限りません。
サイトの管理を依頼している人なら、「入力とSQLの命令を分ける対策を、必要な箇所で行っているか」と担当者へ確認することができます。内部のコードを読めなくても、対策の目的を共有する助けになります。
脆弱性という言葉は、攻撃に悪用され得る弱点を指します。SQLインジェクションのニュースでは、入力の扱いに弱点があり、保存情報を操作する命令が変えられた可能性があると読めれば、被害と対策の説明を追いやすくなります。
