なぜPHPアプリにセキュリティホールが多いのか?

第5回 まだまだ残っているSQLインジェクション

この記事を読むのに必要な時間:およそ 4 分

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文を生成する場合,すべてのデータは信用できないデータとして処理するべきです。

著者プロフィール

大垣靖男(おおがきやすお)

University of Denver卒。同校にてコンピュータサイエンスとビジネスを学ぶ。株式会社シーエーシーを経て,エレクトロニック・サービス・イニシアチブ有限会社を設立。
オープンソース製品は比較的古くから利用し,Linuxは0.9xのころから利用している。オープンソースシステム開発への参加はエレクトロニック・サービス・イニシアチブ設立後から。PHPプロジェクトでは,PostgreSQLモジュールのメンテナンスを担当している。

URLhttp://blog.ohgaki.net/

著書

コメント

  • preg_match のバリデーション例

    preg_match の不完全なバリデーションの例の答えですが、以下の説明が間違っています。

    「$_GET['id']中の最初の1行目が数字だけで構成されているかチェックしています。2行目以降にどのような文字列が入っていても構いません。」

    私の調べた限りでは、2行目以降もチェックされます。
    D 修飾子を付けない場合、最後の文字が改行でもマッチするというだけです。

    つまり、preg_match('/^[0-9]+$/', $_GET['id']) では、"1\n" は TRUE ですが、"1\n;SELECT * FROM product" は FALSE です。

    preg_match() で調べる文字列に改行が含まれない場合、D 修飾子を付けた方が安全だとは思いますが、この問題では「バリデーションには明らかな間違いがある」とは言えないのではないでしょうか。

    この問題では、register_globals = On の環境で $id が上書きされて SQL インジェクションが発生するという可能性の方が高いように思います。

    Commented : #2  komura (2007/06/10, 11:03)

  • はじめまして。

    はじめまして。
    記事を拝見し、すこし思ったのですが
    > なぜPHPアプリにセキュリティホールが多いのか?
    に関しては、「まずいサンプルが多い」のが一番の原因じゃないでしょうか。
    本記事の場合、非常に要点を抑えておられるとは思うのですが、サンプルコードの

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

    は、せめて $id を初期化しておいてください。(もしくは、if ブロックの中で query発行をするか。)

    Commented : #1  通りすがり (2007/06/10, 07:15)

コメントの記入