SQLインジェクション（英: SQL injection）とは、アプリケーションのセキュリティ上の不備を意図的に利用し、アプリケーションが想定しないSQL文を実行させることにより、データベースシステムを不正に操作する攻撃方法のこと。また、その攻撃を可能とする脆弱性のことである。
SQLに別のSQL文が「注入 (inject)」されることから、「ダイレクトSQLコマンドインジェクション」もしくは「SQL注入」と呼ばれることもある。
アプリケーションが入力値を適切にエスケープしないままSQL中に展開することで発生する。
次のようなSQLを発行することを考える。
SELECT * FROM users WHERE name = '（入力値）';
ここで入力値に "t' OR 't' = 't" という文字列を与えた場合を考えると、SQL文は次のように展開される。
SELECT * FROM users WHERE name = 't' OR 't' = 't';
このSQL文では条件が常に真となるため、nameカラムの値にかかわらず、全レコードが選択される。このような攻撃は、入力値が1つだけのものには限られない。
これを応用したものに、SELECTの条件式にデータベース内の情報を確認するようなサブクエリーを含ませ、その抽出の成否によって本来参照することのできないテーブル名などのデータベース内の情報を知るといった、ブラインドSQLインジェクションと呼ばれる手法も存在する[1]。例えば、「テーブル名の1文字目がaのテーブルは存在するか？」「aで始まり2文字目がbのテーブルは存在するか？」などの情報を確認するサブクエリーを含め、その抽出の成否を丹念に集めていけば、テーブル名や項目名を確認できる。
また、複数のSQL文を注入することによるデータの破壊や改竄、ストアドプロシージャを実行されることによる情報の漏洩や改竄、OSコマンドの実行などを引き起こすこともできる場合がある。
SQLインジェクションは、入力値を適切にエスケープすることで防ぐことができる。上述の文字列中への展開では、メタ文字 ' を '' （単一引用符2つ）にエスケープすることにより、次のようなSQLになり、意図されたとおりnameカラムが "t' OR 't' = 't" という値を持つレコードが選択される。
（単一引用符を2回連続して記述すると、ひとつの ' という文字リテラルとして認識される。）
SELECT * FROM users WHERE name = 't'' OR ''t'' = ''t';
ただし、データベースシステムによっては、単一引用符以外の囲み文字を用いて文字列リテラルを示すことができるものが存在する。例えば、MySQLでは動作モードによっては二重引用符を文字列の囲み文字として使用可能である[2]。このような環境下で、上記のようなSQL文の生成を行うプログラム中で二重引用符を囲み文字を用いているなら、二重引用符をエスケープする必要がある。
他には、文字列リテラル中の単一引用符を表現する方法が複数存在するものもある。例えばMySQLやPostgreSQLのバージョンや設定次第では、エスケープ文字としてバックスラッシュを使用して特殊文字を表現することが可能である。この方法を用いると \' や \047 （注：047は単一引用符の8進表記）という文字列が文字列リテラル中の単一引用符を表すことになる。このようなデータベースシステムでは、単純に単一引用符を二重化するだけではSQLインジェクション対策としては不充分である。例えば入力値に "\' OR 1=1 --" という文字列を与え、そこに含まれる単一引用符を単純に二重化すると、上述のSQLは以下のように解釈される。
SELECT * FROM users WHERE name = '\'' OR 1=1 --';
二重化された単一引用符のうち、前者は前置されたバックスラッシュと合わさって文字列リテラル中の単一引用符を意味することになり、後者は文字列リテラルの終端を意味することになる。ここで -- 以降がコメントと見なされれば、このSQLの条件は常に真となり、SQLインジェクションが成立することになる。つまり、バックスラッシュもエスケープを必要とする。
更には、文字コードによっては2バイト目にバックスラッシュが含まれる文字を有するものが存在し、エスケープ処理を行うライブラリによっては日本語をうまく扱えないために、前述のようなエスケープシーケンスとしてバックスラッシュが機能することもありえる。データベースにSQLを発行する言語側の事情により、文字コード変換が自動的に発生することに伴って、前述のようなエスケープシーケンスとしてバックスラッシュが機能することもありえる[3]。
SQLインジェクションを防ぐには、入力値を適切にエスケープできればよい。しかしながら、前節に挙げたように、入力値を適切にエスケープすることは、それほど単純に行えるわけではない。データベースシステムやライブラリによっては、バインド機構と呼ばれる仕組みを用いてエスケープ処理不要で安全にSQLを発行する方法が設けられているものがあり、対策もれを防ぐ上で有用である。
SQLインジェクションが発生した実例を年別に挙げる。年は発生もしくは判明時点とする。
2008年3月頃より、SQLインジェクションによるウェブサイトの改竄が多発している[6]。
情報が流出した場合には企業存続の危機につながりかねない。情報処理推進機構 (IPA) はSQLインジェクションによる被害からの復旧コストは1億円を超えうるとしており[7]、実際にサウンドハウスの事例では補償のみでも122,884名に1,000円相当の期限付きクレジットを負担している。補償のほかにも専門家による調査、システムの入れ替え、顧客対応、一時閉鎖による営業機会の逸失、風評被害といった負担があり、SQLインジェクションも含めセキュリティ対策は厳密に行うべきである。
NRIセキュアが企業を対象に2007年度に行ったセキュリティ診断の統計では、41%のウェブサイトが不正アクセス可能であり、そのうち22%でSQLインジェクション攻撃に対する脆弱性があった[8]。また、この統計で、SQLインジェクションの脆弱性のうち84%が、対策は行っていたが抜け穴が存在した。
未登録
IPFS未登録
📡 0ピア
N=1
CRITICAL
PQS C44