WEB脆弱性のインジェクションとは？
前回の『WEB脆弱性のインジェクションとは？』に『対策』を追記してみました。
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
インジェクション（injection）の意味は、内部に何かを注入することです。
そして、WEB脆弱性のインジェクションには、以下の３つがあります。
- SQLインジェクション
- OSコマンドインジェクション
- HTTPヘッダインジェクション
つまり、SQL、OSコマンド、HTTPヘッダの各々に、Webページから悪意のコマンドをインジェクションされることなのです。
◆SQLインジェクション
たとえば、$uidと$passhをWebページから入力（POST)される以下のSQLがあったとします。
$query = "SELECT * FROM usr WHERE uid = '$uid' AND pass = '$passh'";
$uidに「taro'--」と入力されたら、以下のように展開されます。
$query = "SELECT * FROM usr WHERE uid = 'taro'--' AND pass = ''";
すると、SQLで「--」はコメントになりますので、パスワードがなくても以下のSQLが発行されてしまうのです。
$query = "SELECT * FROM usr WHERE uid = 'taro'";
これ、Delete文もインジェクションされるケースもあり、私は実際にテストで体験しております。DBがクリアされました！
・対策１
バインド機構を利用します。
バインド機構とは、実際の値がまだ割り当てられていない記号文字（プレースホルダ）を使用して、あらかじめSQL文の雛形を用意し、後に実際の値（バインド値）を割り当ててSQL文を完成させるようにします。
・対策２
対策１のバインド機構が利用できない場合は、入力されるパラメータや、データベースに格納される情報や、SQL文を構成する全ての変数や演算結果に対し、エスケープ処理を行います。
エスケープ処理の対象は、SQL文にとって特別な意味を持つ記号文字（たとえば、「'」→「''」、「\」→「\\」等 ）が対象です。
尚、特別な意味を持つ記号文字は、利用しているデータベースエンジンによって異なるので、それぞれに応じて対策を行います。
・対策３
たとえば、データ検索のみのケースでは、削除や更新系のSQLが使えないようにＤＢの権限設定を行います。
◆OSコマンド・インジェクション
たとえば、$fromをWebページから入力（POST)される以下のopen文があったとします。
$from =~ s/"|;|'|<|>|\|| //ig; open(MAIL, "|/usr/sbin/sendmail -t -i -f $from");
$from に「`touch[0x09]/tmp/foo`」と入力されたら、以下のように展開されます。
$from =~ s/"|;|'|<|>|\|| //ig; open(MAIL, "|/usr/sbin/sendmail -t -i -f `touch[0x09]/tmp/foo`);
すると、touchコマンドが実行されてしまいます。
・対策１
OSコマンドを起動できる言語機能の利用を避けます。
たとえば、Perlでは、open関数でなくsysopen関数を使用すれば、OSコマンドを起動することができません。
・対策２
対策１が利用できない場合は、引数に埋め込む前にチェックをかけ、本来想定する動作のみが実行されるようします。
◆HTTPヘッダ・インジェクション
たとえば、$numをWebページから入力（POST)される以下のHTTPのLocationがあったとします。
$cgi = new CGI; $num = $cgi->param('num'); print "Location: http://example.jp/index.cgi?num=$num\n\n";
$num に「3%0D%0ASet-Cookie:SID=evil」と入力されたら、以下のようなクッキーが発行されてしまうのです。
Set-Cookie: SID=evil
・対策１
ヘッダの出力を直接行わず、Webアプリケーションの実行環境や言語に用意されているヘッダ出力用APIを使用します。
・対策２
対策１が利用できない場合は、ヘッダの出力時に想定外の改行を許可しないようにします。
これは、HTTPヘッダは改行によって区切られる構造となっているため、これを許すと、任意のヘッダフィールドや任意のボディを注入される原因となるからです。
