WEBプログラマー必見！WEB脆弱性基礎知識最速マスター

今回、WEBアプリケーションを開発にあたってのWEB脆弱性を、以下の一覧にまとめてみました。

このまとめがWEBアプリケーション開発の参考になれば幸いです。

• インジェクション
• クロスサイト・ス クリプティング
• セッショ ン・ハ イジャック
• アクセス制御 や認可制御の欠落
• ディ レクトリ・トラバーサル (Directory Traversal)
• CSRF（ク ロスサイト・リクエスト・フォージェリ）

尚、本コンテンツを作成するにあたって、以下のリンク先を大変参考にさせて頂きました。

下記のリンク先は、凄く勉強になりました。謹んで御礼申し上げます。

• 参考リンク
  http://www.ipa.go.jp/security/vuln/documents/website_security.pdf

追記：

すでに、はてブで指摘されているよ うに、本コンテンツは、参考リンク先で勉強したノートです。

したがって、本コンテンツより、参考リンク先で勉強することを強くお薦めします。

追記（5/23）：

以下の暗号化の基礎知識もあわせてご利用くだ さい。

• WEBプログラマー必見！WEB暗号化基礎知識最速マスター - 燈明日記

---

■ インジェクション

◆ インジェクションとは？

インジェクション（injection）の意味は、内部に何かを注入することです。

そして、WEB脆弱性のインジェクションには、以下の３つがあります。

1. SQL インジェクション
2. OSコ マンドインジェクション
3. 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が使えないようにＤＢの権限設定を行います。

・対策４

あとは、SQLのエ ラーメッセージをWeb画面に表示しないとか、hiddenパラメータに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ヘッダは改行によって区切られる構造となっているため、これを許すと、任意のヘッダフィールドや任意のボディを注入される原 因となるからです。

---

■ クロスサイト・スクリプティング

◆ クロスサイト・スクリプティングとは

普通CGIな どWebアプリケーションは、Webページから検索のキーワー ド入力や個人情報の登 録入力などを処理して、Webページとして出力します。

ここで、Webページへの出力処理に問題があると、そのWebページにスクリプ トなどを埋め込まれてしまうことがあります。

このようなスクリプトのインジェクション（注入）を、特にクロスサイト・スクリプティング攻撃と言います。

対策としては、入力されたHTMLテキストを出力する際にエスケープ処理を行い、 HTMLテキストを許可しない方法があります。

どうしても、HTMLテキストが必要な場合は、構文解析を行 い、「ホ ワイトリスト方式」で許可する要素のみを抽出します。

また、共通の対策としては、HTTPレスポンスヘッダのContent-Typeフィールドに文字コー ド(charset)の指定を行います。

◆ 補足

・エスケープ処理

エスケープ処理には、Webページの表示に影響する特別な記号文字（「<」、「>」、「&」、「"」、「'｣など）を、

HTMLエンティティ（「&lt;」、「&gt;」、「&amp;」、「&quot;」、 「&#39;」など）に置換します。

また、URLを 出力するときは、「http://」や 「https://」で始まるURLのみを許可するようにします。

これは、「javascript:」の形式で始まる URLがあるからです。

以下は、上記の置換をするPerlでのソースです（前に書いた記事の引用です）。

sub htmlf {
    my ($strhtml) = @_;
    $strhtml =~ s/&/&/g;
    $strhtml =~ s/>/>/g;
    $strhtml =~ s/</&lt;/g;
    $strhtml =~ s/"/&quot;/g;
    $strhtml =~ s/'/&#39;/g;
    return $strhtml;
}

http://d.hatena.ne.jp/chaichanPaPa/20080329/1206748795

・ホワイトリスト方式

リストに登録された内容に一致する文字列の通過を「許可」す る方式です。

未知の攻撃パターンにも有効であり、漏れが生じにくい点で安全性は高いです。

ちなみに、ブ ラックリスト方式は、ホワイトリスト方式の逆で、リストに登録された内容に一致する文字列の通過を「禁止」する方式です。

これは、未知の攻撃パターンを検出できない可能性があり、漏れが生じやすいという性質あります。

・HTTPレスポンスヘッダの文字コード指定

HTTPレスポンスヘッダに文字コードを指定していないと、ブラウザは、 文字コードを推測して画面表示を処理します。

たとえば、UTF-7に推測された場合、上記のような「エス ケープ処理」を施してもエスケープをスルーしてしまうケースがあるとのことでした（参考リンク参照）。

---

■ セッション・ハイジャック

◆ セッション・ハイジャックとは

HTTPは、ステートレスなので、普通は、ステートを引き継ぐセッション管理ができません。

しかし、ログインが必 要なサイトでは、セッション管理がないと実現ができません。

そのために、クッキーが考案され、クッキーにステート（セッションID）を保存することにより、セッション管理を実現します。

しかし、セッション管理がクッキーにより実現できても、その不備を狙うWEB脆弱性があり、それをセッション・ハイジャック攻撃と言います。

セッション・ハイジャック攻撃には、以下の３通りがあります。

1. セッションIDの推測
2. セッションIDの盗用
3. セッションIDの固定化（Session Fixation）

◆ セッションIDの推測

悪意のある人は、セッションIDの生成規則を割り出し、有効なセッションIDを推測します。

これにより、善意の利用者に成りすましすることができるのです。

対策：セッションIDは、生成ア ルゴリズムに安全な擬似乱数生成 系を用いるなどして、予測困難なものにします。

◆ セッションIDの盗用

悪意のある人は、罠を仕掛けたり、ネッ トワークを盗聴したりし、利用者のセッションIDを盗みます。

これにより、善意の利用者に成りすましすることができるのです。

対策：セッションIDをURLパラメータに格納しないようにしたり、HTTPS通信で利用するCookieには secure属性を加えます。

◆ セッションIDの固定化（Session Fixation）

悪意のある人は、以下のような『何らかの方法』で、自分が取得したセッションIDを善意の利用者のセッションIDに送り込みます。

これにより、善意の利用者に成りすましすることができるのです。

対策：ログイン成功後に、新しくセッションを開始するようにします。

・『何らかの方法』の一例

1. 悪意の利用者が、BBS掲示板等へ「セッションIDを送り込む細工をされたURL」を貼り付けます。
2. 善意の利用者は、そのURLをクリックし、ログインします。
3. 悪意の利用者は、送り込んだセッションIDを使って善意の利用者のページを閲覧できるようになります。

・細工されたURLの例

<a href="javascript:document.cookie='PHPSESSID=aaa;expires=Thu, 1-Jan-2011 00:00:00 GMT';location.href='login.php'">click me!</a>

・説明

悪意のある人が、予め用意したセッションID（例ではクッキーのPHPSESSID=aaa）をdocument.cookieで善意の利用者 のに送り込み、ログインページに遷移します。

するとその後、悪意の利用者は、そのセッションIDでログインすることにより、善意の利用者に成りすましすることができるようになるのです。

---

■ アクセス制御や認可制御の欠落

◆ アクセス制御の欠落と対策

アクセス制御の欠落とは、ログインが必要なサイトでは、ログイン情報によりアクセス制御を掛けますが、たとえば、そのログイン情報がメー ルアドレスだった場合は、他人にも知られ得る情報であり、そのような情報の入力だけでログインできてしまうのは、アクセス制御機能が欠落している と言えます。

アクセス制御の対策は、他人にも知られ得る情報でなく、パスワードなどの入力を必要とするように、Webアプリケーションを設計する必要があ ります。

◆ 認可制御の欠落と対策

認可制御の欠落とは、上記の「アクセス制御の欠落」をなくして、ログインを実装しても、ログイン者が他のログイン者の情報（データベース）に アクセスできてしまうことがあります。このような実装は、認可制御機能が欠落していると言えます。

認可制御の対策は、ログイン者がアクセスできる情報（データベース）の範囲をつねに考慮するように、Webアプリケーションを設計する必要が あります。

---

■ ディレクトリ・トラバーサル(Directory Traversal)

◆ ディレクトリ・トラバーサルとは？

「../../」のような相対パスを使 用し、システム内の任意ファイルへアクセスする攻撃手法をディレクトリ・トラバーサルと言います。

システム内のディレクトリ間を自由に横断（トラバー ス）できることが攻撃名称の由来で、パス・トラバーサルとも呼ばれます。

対策は、CGIでは、GET(引数)とPOST（hidden）で、ファイル名のみで、ファイルパスを指定しないように設計します。

また、万が一、ファイル名にファイルパスを付加された場合を想定して、そのようなパスを削除するように設計します。

◆ ディレクトリ・トラバーサル対応のサンプルプログラム

#!c:/perl/bin/perl.exe
use strict;
use File::Basename;
use CGI;

my $form = new CGI;
my $file_name = $form->param('file_name');
local $/;

my $dir = 'c:/wk/';                # パス情報をプログラム内で持つ
$file_name = basename($file_name); # パスを指定されてもファイル名だけにする
                                   # openは、パス名とファイル名で連結する
open(my $fh, '<', $dir . $file_name) or die "$file_name, open err ($!)";

my $wk = <$fh>;
print <<"HERE1";
Content-type: text/plain; charset=Shift_JIS;

<html>
<body>
<h1>test</h1>
<p>$wk</p>
</body>
</html>
HERE1

尚、上記は、XSS対 応にはなっていませんので、ご注意を！

XSSに関しては、『クロスサイト・スクリプティング』を参照してください。

◆ 補足

『./』は自ディレクトリです。

『../』は、親ディレクトリです。

たとえば、bbbディレクトリにtest.txtがあったとします。

すると、

cat /aaa/bbb/test.txt

と

cat /aaa/bbb/ccc/ddd/../../test.txt

は、同じになるのです。

---

■ CSRF（クロスサイト・リクエスト・フォージェリ）

◆ クロスサイト・リクエスト・フォージェリとは？

普通、Webページの入力項目に対して入力をして、書き込みを押すと、その入力データがサーバーに送 られます。

たとえば、このWebページで、入力をしないで、悪意のあるページにアクセスしたとします。

すると、それだけで悪意のある入力データがサーバーへ送られる可能性があるのです。

そして、このような攻撃をCSRF（クロスサイト・リクエスト・フォージェリ）と言います。

たとえば、確認のページが、以下のようになっていたとします。

<form action="commit.php" method="post">
<input type="hidden" name="new_name" value="脆弱 太郎">
<input type="hidden" name="new_address" value="大阪府">
<input type="submit" name="back" value="戻る">
<input type="submit" name="commit" value="実行">
</form>

このときに、実行を押さず、以下のような悪意のページにアクセスしたら…。

<form action="http://○○/commit.php" method="post" name="f1">
<input type="hidden" name="new_name" value="いぱくん">
<input type="hidden" name="new_address" value="東京都">
</form>
<script>document.forms['f1'].submit();</script>

アクセスしただけで、submit()が実行されて、脆弱 太郎・大阪府でなく、いぱくん・東京都が書き込みされてしまうのです。

これ、mixi（ミクシィ）の ような会員制のサイトでは、自分のIDで悪意の第三者に書き込みがされてしまうのです。

当然、その書き込みが、不正送金、商品購入、退会処理の場合があるわけです！

CSRF対策としては、使用者と開発者では以下があります。

◆ 使用者としてのCSRF対策

とにかく、会員制のサイトにログインしたら、ログアウトするまではサイト以外のページにアクセスしない。

◆ 開発者としてのCSRF対策

更新ページで、秘密情報挿入やRefererチェック等で、なりすましを厳しく チェックします。