安全なWebアプリケーションの実現に向けて：星野君のWebアプリほのぼの改造計画（最終回）（2/3 ページ）

[杉山俊春, Illustrated by はるぷ，三井物産セキュアディレクション株式会社]

検査項目をしっかり定義

星野君　「大まかにいうと、Webアプリケーション開発で、『セキュリティテスト』っていう工程を明確に定義しましょうって感じですかね」

赤坂さん　「ほー」

星野君　「実際。『なんとなく大丈夫そう』っていうレベルでしかセキュリティって考えられていない場合が多いから、テスト項目を作りましょうって感じでいろいろ具体例を挙げてました」

赤坂さん　「へぇ〜。具体例ねぇ〜」

　Webアプリケーションの安全性を高めるためには、実際に攻撃パターン（脆弱性の可能性を示唆できるパターン）を試すことが必要となってくる。すべての攻撃パターンを網羅することは難しいが、各攻撃パターンで共通している部分を取り出して検査することで、ほとんどの攻撃を防ぐことが可能となる。

　以下に、代表的な脆弱性4つに対する検査パターンおよび確認事項について示す。これらの項目を実施するだけで格段にセキュリティが向上する。

本番環境に近い環境で行うことが望ましいが、Webアプリケーションの作りによってはサーバの障害につながる恐れがあるのでテスト環境で実施することをお勧めする

●Cross-Site Scripting

［検査パターン例］	「'>"><s>test</s>」
［確認事項］	入力した文字がそのままレスポンスの中に含まれていないか（含まれていたら脆弱） ※ただし、マルチバイト文字を利用したパターンのような特殊な例は対象外（参考：第10回）

●SQL Injection（参考：第2回／第9回）

［検査パターン例］	「'」（シングルクオーテーション）
［確認事項］	SQLエラーが出力されないか
［検査パターン例］	「'||'」または「'%2b'」（連結を意味するSQL文）
［確認事項］	シングルクオーテーションのみの場合と同じ挙動になるか（異なる場合は脆弱）

●OS Command Injection（参考：第7回）

［検査パターン例］	「||/bin/date|」（Linux系の場合）
［確認事項］	時刻が表示されないか

●Directory Traversal（参考：第5回）

［検査パターン例］	「../../../../../../../etc/passwd」（Linux系の場合）
［確認事項］	「/etc/passwd」の中身が表示されないか

【参考リンク】
ITmedia エンタープライズ：
脆弱なWebアプリケーションから脱却する5つのコツhttp://www.itmedia.co.jp/enterprise/articles/0602/02/news001.html

赤坂さん　「なるほどー。こういうチェック項目とか作っておくとよさそうだねー。ちゃんと作ったつもりでも、実際試してみたらダメだったりすることもあるしー」

星野君　「でも、用意した項目をどうやって何に対してチェックするかというのが重要だって高橋さんいってましたよ」

赤坂さん　「何に対してって？」

星野君　「せっかくチェック項目を用意しても、hiddenの項目を忘れるとか、JavaScriptを使ったチェックとかで満足しちゃうだけだと意味ないすよね」（参考：第1回／第3回）

赤坂さん　「あ、そういうことね。検査とかあんまりしたことないとありがちだしね」

ユーザー視点では問題が見えてこない

　検査を行う際には、一般ユーザーの視点ではなく、攻撃者の視点で行うことが重要となる。そのためには、検査補助ツールを利用したり（参考：第3回）、そのほかの方法でリクエストを直接生成したりすることが必要だ。

　例えば、以下のようなログイン画面でのリクエストについて考える。

POST /login.php HTTP/1.0 Accept: */* Referer: http://www.example.com/ Accept-Language: ja User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) Host: www.example.com Cookie: session=cbda6984d2ecc537aef07205ae001013 login_id=black_cat&password=testpass&mode=login&test=aaa

　この場合、画面上では、入力項目が2つ（ログインID、パスワード）のみであるが、実際に検査すべき項目は5つ（パラメータのlogin_id、password、mode、testの4つと、Cookieのsession）となる（※Cookie以外のヘッダも利用している場合はそのほかのヘッダも検査すべき対象となる）。

　この5つの項目に対して、前述の脆弱性ごとの検査パターンを適用する必要がある。各パラメータの用途が明確な場合、検査パターンを省略することも可能であるが、思い込みによる見落としの危険があるため、ブラックボックステスト【注】で行うことが望ましい。

【注】ブラックボックステスト
Webアプリケーションの内部構造が分からない状態で検査を行う方法。Webアプリケーションの挙動から問題を判断する

　また、このようにリクエストを直接見ることで、例えば管理者のメールアドレスなど、本来ユーザーから渡される必要がないパラメータ（参考：第1回）が含まれていたり、またCross-Site Request ForgeriesのようなCookie以外の要素が推測可能な場合に発生する脆弱性（参考：第4回）が存在していたりといった、ユーザー視点からの操作では見落としてしまうようなことに気付くことができる。

星野君　「……リリース前に検査を必ずしましょう。で、その検査の結果を後で参照できるように保管しておきましょう、って感じの話でしたね」

赤坂さん　「……」

星野君　「……聞いてます？」

赤坂さん　「あ、うん。なんか、ご飯食べたら眠くなってきちゃった」

星野君　「えー……」