PROFILPELAJAR.COM

情報セキュリティ > 脆弱性・攻撃手法 > インジェクション攻撃 > SQLインジェクション

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インジェクションが発生した実例を年別に挙げる。年は発生もしくは判明時点とする。

2005年

2005年3月に発生した、クラブツーリズムのクレジットカード情報を含む個人情報漏洩
同年6月にクラブツーリズムを含む14社への不正アクセスの疑いで中国人留学生が逮捕された。
2005年5月に発生した、価格.comのウェブサイト改竄
手口は公表されていないが、SQLインジェクションによるものであるという説がある。クラブツーリズム事件の犯人は価格.comへの不正アクセスも行っていた。
2005年6月に判明した、アデコの個人情報漏洩 - クラブツーリズム事件と同一犯
2005年8月に判明した、静岡新聞社アットエスの個人情報漏洩 - クラブツーリズム事件と同一犯
2005年11月に発生した、ワコールオンラインショップのクレジットカード情報を含む個人情報漏洩
2005年11月に発生した、キッズオンラインのアカウント情報漏洩

2006年

2006年1月に判明した、スカイソフトのクレジットカード情報を含む個人情報漏洩
スカイソフトは閉店へと追い込まれた。
2006年4月に発生した、るるぶのアカウント情報漏洩
2006年6月に発生した、日本体育協会のウェブサイト改竄

2007年

2007年7月にクレジットカード会社からの調査依頼を受け判明した、@SOLAショップ（運営：丸紅インフォテック、現・シネックスジャパン、委託先：トランスコスモス）のクレジットカード情報を含む個人情報漏洩^[4]

2008年

2008年3月に発生した、トレンドマイクロ、@nifty、クリエイティブメディアのウェブサイト改竄
2008年3月に発生した、サウンドハウスのクレジットカード情報を含む個人情報漏洩
過去に設置された不正プログラムを経由して不正アクセスが行われた疑いがある。
2008年4月に発生した、カービューのウェブサイト改竄
2008年5月に発生した、アイドラッグストアー、アイビューティーストアーのクレジットカード情報を含む個人情報漏洩
2008年5月に発生した、富士山マガジンサービスのウェブサイト改竄
2008年6月に発生した、アイリスプラザのクレジットカード情報漏洩
2008年7月に判明した、ナチュラムのクレジットカード情報を含む個人情報漏洩
過去に設置された不正プログラムを経由して不正アクセスが行われた疑いがある。
2008年7月に発生した、米国向けPlayStationのウェブサイト改竄
2008年7月に発生した、独立行政法人石油天然ガス・金属鉱物資源機構のウェブサイト改竄
2008年10月に発生した、ゴルフダイジェスト・オンラインのウェブサイト改竄

2010年

2010年1月に発生した、モンベルのクレジットカード情報漏洩
2010年7月に発生した、コーエーテクモホールディングスのGAMECITY会員の個人情報漏洩^[5]

2011年

2011年4月から発生している、ソニーのPlayStation Networkの個人情報漏洩に始まる、ソニーグループの個人情報漏洩。

2013年

2013年4月に判明した、エクスコムグローバルのクレジットカード情報漏洩
10万9112件のカード名義人名、カード番号、カード有効期限、セキュリティコード、申込者住所が外部へ流出したことを確認。

2008年3月頃より、SQLインジェクションによるウェブサイトの改竄が多発している^[6]。

情報が流出した場合には企業存続の危機につながりかねない。情報処理推進機構 (IPA) はSQLインジェクションによる被害からの復旧コストは1億円を超えうるとしており^[7]、実際にサウンドハウスの事例では補償のみでも122,884名に1,000円相当の期限付きクレジットを負担している。補償のほかにも専門家による調査、システムの入れ替え、顧客対応、一時閉鎖による営業機会の逸失、風評被害といった負担があり、SQLインジェクションも含めセキュリティ対策は厳密に行うべきである。

NRIセキュアが企業を対象に2007年度に行ったセキュリティ診断の統計では、41%のウェブサイトが不正アクセス可能であり、そのうち22%でSQLインジェクション攻撃に対する脆弱性があった^[8]。また、この統計で、SQLインジェクションの脆弱性のうち84%が、対策は行っていたが抜け穴が存在した。