SQLインジェクションを防ぐ対策とは｜わかりやすく仕組みを解説
Webアプリケーションにおいて、典型的なサイバー攻撃、「SQLインジェクション」。 2005年頃から、データベース・セキュリティ・コンソーシアム（DBSC）などでも言及されるようになり、今でも被害を出すサイバー攻撃の一つとして知られています。 特に、SQLインジェクションは、システム開発部門など開発に携わっている方でないと、理解が難しいかもしれません。 本記事では、SQLインジェクションが起こる仕組みや、SQLインジェクションによってもたらされる被害、対策について、分かリやすく解説いたします。
目次
そもそも、SQLって？
SQLインジェクションの解説をする前に、まずはSQLについて解説いたします。 SQLとは、リレーショナルデータベースで利用される言語で、「シーケル」または「シークェル」と読みます。 SQLでは、大きくデータ作成、データ読み込み、データ削除、データ更新の4つの作業を行うことができます。 この4つの作業をまとめて「CRUD」と呼びます。 ISO（国際標準化機構）によって規格化されているため、ほとんどのデータベースで汎用的に使うことができます。
SQLインジェクションとは？
リレーショナルデータベースで利用される言語「SQL」に、不正なプログラムを注入するサイバー攻撃の総称を指します。 インジェクションとは、英語を直訳すると「注入・挿入」となります。
独立行政法人 情報処理推進機構（IPA）が発行する情報セキュリティ白書2019によれば、JVN iPedia に登録されたソフトウェア製品の脆弱性対策情報では、「SQLインジェクション」は3.2%と少ない割合ですが、2018年のSQLインジェクションの被害事例の中には、個人情報が数十万件流出したものもあり、非常に警戒すべき攻撃の一つと言えます。
＜参照：情報セキュリティ白書2019＞
また2019年、GMOペパボが運営するレンタルサーバの「ロリポップ！」が受けた攻撃のうち、およそ47%が「SQLインジェクション」、続いて「クロスサイトスクリプティングが」20%弱、「OSコマンドインジェクション」が11%ということが、WAFを提供する株式会社ジェイピー・セキュアの調査によって明らかになっています。
＜参照：JP-Secure Labs Report Vol.04＞
クロスサイトスクリプティングとの違い
SQLインジェクションと似たサイバー攻撃として、クロスサイトスクリプティングがあります。 SQLインジェクションが、不正なコードの断片をSQLに挿入し、発動させることで直接データベースを攻撃するのに対し、クロスサイトスクリプティングは、脆弱性のあるサイトを利用し、ユーザーの個人情報やパソコンを乗っ取るのが目的です。
クロスサイトという名前の通り、脆弱性のあるサイトが対象ではなく、あくまでそのサイトを踏み台にし、訪れたユーザーを別のサイトに誘導し攻撃（クロス）することから、この名前がついたとされています。
クロスサイトスクリプティングでは、脆弱性のあるWebサイトにスクリプトをつけたURL（罠）などを貼っておきます。 ユーザーがクリックすると、スクリプトが実行され、偽のページにリダイレクトされ、個人情報が流出したり、マルウェアに感染したりします。 主に、スクリプトでは、JavaScript、htmlタグが悪用されるケースが大半です。
SQLインジェクションの仕組み
SQLインジェクションの標的になるサイトとしては、大量のデータを保有し、SQLで制御が必要な、ショッピングサイト、ポータルサイト、決済サイトなどが当てはまります。
まず、SQLサーバ（データベースサーバ）を呼び出す命令文を作成します。 一般的には、IDやパスワードの入力画面は不正な文字列を入力していないかチェックする機能が備わっていますが、なんらかの原因でSQLの構文に脆弱性が存在している場合、またはSQL自体の脆弱性などを悪用し、不正なSQLを実行します。
有名なのが(--)ダブルハイフンを入力することで、コメントとし無視するというSQL上に存在するセキュリティホールです。 (--)ダブルハイフン以下の構文は全て無効化され、ハッカーにとって都合の良い構文を作成できてしまい、その結果、データベースの不正アクセスやデータベースのクラッキングなどが可能になってしまいます。
SQLインジェクションの種類
SQLインジェクションには、大きく分けて4つの種類があります。
エラーベースSQLインジェクション
データベース（DB）に対し、故意にエラーメッセージを吐かせるインジェクションを行います。 SQLサーバから返ってきたエラーメッセージをもとに、対象のデータベースサーバの脆弱性やセキュリティ強度を把握します。 ここで得た情報をもとに、次の攻撃のための準備に移ります。
ブラインドSQLインジェクション
不正なSQLを用いて、SQLサーバからの応答や動作をもとに、データベースの構造を断片的に調査し、全貌を把握します。 こちらは、エラーベースSQLインジェクションのように、攻撃者が直接的にデータベースから結果やデータを取得するわけではないことから、「ブラインドSQLインジェクション」と呼ばれます。
マルチプルステートメント
セミコロンで、SQL文を区切ることで、複数のSQL文を連結させる「マルチプルステートメント」を使ったSQLインジェクションもあります。 例えば、構文をセミコロンで区切ることで、攻撃者に都合のよい構文がand条件として設定されてしまい、データの書き換えや奪取などを可能にしてしまいます。
UNIONインジェクション
一般的に、SQLはセミコロンなどのデリミタで区切り、複数のSQL文の連結させることができます。 また、このほかにUNION句を使い構文を作成する方法もあります。 この手法を使ったSQLインジェクションを「UNIONインジェクション」と呼びます。 UNION句を使用すると、今まで使ったSQL文の結果を結合し、1つにまとめることができます。
ただし、UNION句は「SELECT句に同じデータ型のカラムがある、または変換可能」「SELECT句のカラムが同数」の2つの条件を満たしていないと使用できません。
SQLインジェクションによる被害事例
SQLインジェクションによる被害事例は、標的型攻撃やマルウェアに比べると、件数は少ないですが、中には甚大な被害に発展するケースもあります。
株式会社釣りビジョン
2019年1月、株式会社釣りビジョンのデータベースサーバに保管されていた顧客情報63,000件あまりが流出しました。 SQLインジェクションにより、データベースサーバに不正アクセスされ、奪取されたとしています。 その後、被害防止拡大の対策として、該当のIPアドレスのブロック、Webサーバの脆弱性を改善しました。
株式会社MS&Consulting
2018年5月に、サーバに不正アクセスされ、登録された6119名の個人情報が流出しました。 URLの末尾のパラメータに不正なデータベースコマンドをインジェクションさせ、偽のWebサイトへ誘導し、個人情報の奪取を図ったとされています。
原因は、WAFの設定ミスによるもので、5月中にWAFの再設定と、Webサイトに登録されている登録者のパスワードを変更、一般社団法人日本情報経済社会推進機構（JIPDEC）に対して報告を行うなどの措置により、事態は終息に向かいました。
株式会社サウンドハウス
2008年に起こった情報流出事件で、約97,000件に及ぶ個人情報が流出しました。 うち、クレジットカード情報が20,000件含まれていたため、大規模な情報漏えい事件として知られています。 SQLインジェクションにより、データベース・サーバへバックドアが作られ、不正ファイルを埋め込まれました。 その結果、不正プログラムにより、顧客データが定期的に抜き取られる事態に発展してしまいました。
SQLインジェクションを防ぐ対策
SQLインジェクションは、言語の脆弱性を縫うようにして、調査あるいは攻撃を行ってくるため、複数のセキュリティ対策を行うことが重要です。
.NET LINQ、PL/SQLなどの言語を使用する
SQLには、インジェクションをされてしまうさまざまな要因が存在します。 一つの対策として、.NET LINQ、PL/SQLなどロジックの中にソースコードとしてSQLを記述できる開発言語を選ぶことです。 これらを使うことで、文字列として扱わずに済むため、インジェクションのリスクを下げることができます。 ただし、これはゼロから開発する場合に限る話であり、既存のプログラムのSQLを他言語に置き換える場合には、多額のコストと長い歳月がかかるため、あまり推奨できる対策ではありません。
構文すべての変数をエスケープ処理する
エスケープ処理とは、開発言語で使用される特別な意味を持っている文字あるいは記号をルールに沿って、その特別な意味を無効化し、文字列として扱えるようにする、または、文字列に特別な意味を持たせるようにする処理のことを指します。 エスケープ処理する対象は、特別な意味を持つ、'（シングルクオーテーション）や”（ダブルクオーテーション）といった記号や文字になりますが、データベースエンジンによって、特別な意味を持つ記号や文字は異なり、付与される意味も異なるので、利用しているデータベースエンジンに合わせた対策を行いましょう。 後述するバインド機構が使える場合は、そちらを実行したほうが根本的な解決が行なえます。
クエリにバインド機構（メカニズム）を実装
文字列としてSQL構文を作成した場合、エスケープ処理漏れなどが発生した際に、入力値がSQL実行の引き金になる可能性があるだけでなく、SQLインジェクションの被害に遭う可能性も高いです。 バインド機構（メカニズム）とは、あらかじめSQLのクエリを予約（プリペアドステートメント）し、後からそれを各条件（プレースホルダ）に、バインド値を付与し、SQLを書き出すデータベースの機能のことを指します。
バリデーションチェック
バリデーションは、直訳すると「妥当性の確認」や「検査」という意味になります。 ITでは検証という意味で用いられるケースが多いです。 バリデーションは、大きく分けると、「入力バリデーション」、「ロジックバリデーション」、「出力バリデーション」の3つがあります。
入力バリデーションでは、入力値がセキュリティ上OKか妥当性を確認します。 不正なデータによる不規則な処理が行われないように保つのが、入力バリデーションの役割です。 セキュリティ上における妥当性、また入力値の妥当性を区別します。 いわゆるホワイトリスト方式で、検証されることが一般的です。
次に、ロジックバリデーションとは、処理そのものが適切になっているかどうか、モジュール、ライブラリ、メソッドに対して検証します。
最後が出力バリデーションですが、ここでは出力値のチェックを行います。 いわゆる、「フェイルセーフ対策」として機能します。多くはバグの処理になります。
データベースサーバのログの監視／解析
最後に、データベース・サーバのログの監視と解析です。 どこの範囲のデータを抽出されたのか、書き換えられたのかを解析することができ、重要な対策の一つです。 ただし、SQLインジェクションの中には、Cookieの攻撃が埋め込まれ、サーバのログに痕跡が残らないものもあり、全てを検知できるわけではありません。 また、起こってから、被害実態をいち早く検知・把握し、追跡・原因究明するためのものであり、水際の対策にはなりません。 上述した対策と合わせて行いましょう。
まとめ
SQLインジェクションは、攻撃の実態が見えにくく、気がついたときには大量の個人情報や機密データが持ち出されており、甚大な被害に遭うというケースも。 SQLのエスケープ処理、多層バリデーション、バインドメカニズムの実装、そしてログ管理など、多岐にわたる入念なセキュリティ対策に役立てましょう。
