SQLインジェクションは古くから知られている代表的なWebアプリケーションの脆弱性です。JavaScript関連の脆弱性に比べると対処が非常に簡単であるにも関わらず，まだまだ多くのアプリケーションがSQLインジェクションに脆弱です。SQLインジェクションに脆弱なアプリケーションはPHPアプリケーションに限った問題ではありません。Java，Perlなど，ほかの言語で作成されたWebアプリケーションにもまだまだ多くのSQLインジェクション脆弱性が残っていると考えられます。

重要なのは「正しく行えばSQLインジェクション対策は簡単」であることです。

SQLインジェクションの動作原理

SQLインジェクションの動作原理は単純で，解説するまでもないと思いますが，簡単に説明します。SQLインジェクションは，動的にSQL文を生成する際のパラメータに，プログラマが意図していない文字列を与えることにより，データを改ざんしたり盗むSQLクエリを実行させることです。

以下のコードはSQLインジェクションに脆弱な典型的な例です。

$res = pq_query('SELECT * FROM product WHERE ID = '.$_GET['id']);

$_GET['id']に“0; DELETE FROM product”が送信されると，適切な権限があれば，productテーブルのすべてのデータが削除されます。UNIONクエリを利用するとデータベース内のすべてのデータを自由に取得可能となる場合もあります。

間違ったSQLインジェクション対策

SQLインジェクションがなくならない原因の一つに，間違ったSQLインジェクション対策で完全にSQLインジェクションを防ぐことが可能である，といった誤解があります。

• エラーメッセージを表示しなければSQLインジェクションはできない
• ORMを利用しているのでSQLインジェクションの心配はない
• 入力時にバリデーションしているのでSQLインジェクションの心配はない
• すべての文字列はエスケープしているので心配はない
• 信用できるデータはエスケープなしでクエリに利用できる（信用できないデータだけエスケープすればよい）

これらすべては間違ったSQLインジェクション対策です。

エラーメッセージ抑制による対策

エラーメッセージを表示しなくても，SQLインジェクションによる攻撃は可能です。通常テーブル名，フィールド名は予測しやすい名前が付いています。テーブル名やフィールド名を予測しづらい名前にすることも可能ですが，簡単に防げるSQLインジェクションのために，著しくメンテナンス性を低下させるこのような手法を利用するのは間違ったSQLインジェクション対策といえます。エラーメッセージの抑制はSQLインジェクション対策として無意味でないですが，不十分極まりない対策です。

備考：いずれにせよエラーメッセージにテーブル名，フィールド名，変数名，スクリプトのパスなどシステムの内部構造が分かるようなメッセージを表示してはなりません。これはSQLインジェクション対策以前のセキュリティ上の問題です。

ORMに頼った対策

ORMを利用していても，SQL機能を使用せず，ORMの機能だけで効率的なアプリケーションが作れる訳ではありません。筆者も時々みかけるのですが，ORMだけ利用しているために酷く効率が悪いアプリケーションがあります。このようなアプリケーションはSQLインジェクションに脆弱でなくてもDoSに非常に脆弱です。実行効率の問題もあるので一般的なORMライブラリはSQL文やSQL文の一部を指定してクエリを実行できるようになっています。ORMを利用していてもSQLの基礎知識は必要です。

入力時のバリデーションに頼った対策

仮にHTMLフォームなどからの入力時に完全なバリデーションを試みていても，入力時のバリデーションに不具合があるケースは多くあります。動的にSQL文を作成するコードと入力をバリデーションするコードは別ファイルであることが多く，変数をSQL文の入力値として安全に利用できるか確認するには実行パスをたどって確認しなければなりません。このようなコードでは安全性の維持は容易ではありません。

すべての文字列をエスケープする対策

すべての文字列をエスケープしていてもSQLインジェクションが可能になってしまう場合がいくつかあります。これは不完全な入力バリデーションと組み合わされた場合に発生します。

以下のバリデーションには明らかな間違いがあります。整数を期待している箇所に文字列を許しています。

 if (preg_match('/^[0-9]+$/', $_GET['id'])) { 
 	$id = $_GET['id'];
 }
 $res = pq_query('SELECT * FROM product WHERE ID = '.$id);

 if (ereg('^[0-9]+$', $_GET['id'])) {
 	$id = $_GET['id'];
 }
 $res = pq_query('SELECT * FROM product WHERE ID = '.$id);

ユーザ入力値をSQL文に利用するかしないかに関わらず，すべてのユーザ入力値は検証しなければなりません。上記の例は不完全なバリデーションによりSQLインジェクションが可能になる例ですが，後に解説する正しいSQLインジェクション対策を行っていればSQLインジェクション攻撃は行えません。

別の特殊なケースでは，数値型のコラムによりSQLインジェクションが可能となる場合もあります。データベースのアクセス抽象化ライブラリを利用すると複数のデータベースを同じように利用可能になりますが，データベースエンジンによっては通常のRDBMSでは思いもよらない動作をする場合があります。PHP5からデフォルトでバンドルされ利用可能になったデータベースエンジンのSQLiteのテーブルコラムには，整数，浮動小数点，文字列などのデータ型を指定できます。しかし，実際にはすべて文字列型として保存しています。SQLiteでは数値型のフィールドにセカンドオーダSQLインジェクション攻撃用のSQL文字列を保存させることができます。通常のRDBMSに経験を持つ方には数値型フィールドに文字列が保存されていることは予想できないかもしれません。

信用できないデータだけエスケープする対策

ここまでに紹介した不完全な対策から推測できるように，信用できないデータだけエスケープする対策ではSQLインジェクションを許してしまう可能性があることが分かります。動的にSQL文を生成する場合，すべてのデータは信用できないデータとして処理するべきです。