第14回 Webアプリケーションセキュリティの常識：知ってるつもり？「セキュリティの常識」を再確認（2/4 ページ）

[杉山俊春（三井物産セキュアディレクション），ITmedia]

　Webアプリケーションの脆弱性のほとんどは、開発時のささいなミスから生じる。ブラウザから送信されるデータは、基本的にユーザー側で操作することが可能なため、本来、サーバ側ではユーザーのブラウザから送信される入力はすべて疑って処理を行うべきである。しかし、ブラウザから送信される入力のチェックやサニタイジング（無効化）を行わずに処理させてしまうことにより、意図しない動作を行ってしまうのである。

　代表的な攻撃手法であるSQLインジェクションを例に紹介しよう。

　ユーザー名とパスワードを入力させてログイン処理をする際に、次のようなSQL文を利用しているとする。

$SQL="SELECT * FROM user WHERE userid='$userid' AND password='$password'";

　この文はユーザーに「userid」と「password」を入力させ、それらが一致したレコードが取り出されることを想定している。しかし、ユーザーが悪意を持って次のような入力を行った場合、本来意図した挙動と違う挙動をしてしまう。

userid　　　malicious password　　' or '1'='1

　このような入力によって、実際に実行されるSQL文は

SELECT * FROM user WHERE userid='malicious' AND password='' or '1'='1'

となる。

　これにより、パスワードがわからなくとも、'1'='1'が真であるために認証を回避できてしまう。さらに、認証の回避だけでなく、別のSQLを続けて実行させることも可能となってしまう場合もある。

この場合、システム的に特殊な意味を持つ記号（この場合は「'」（シングルクウォート））をサニタイジング（無効化）していれば攻撃を回避できたはずである。しかし、実際にはこのような攻撃が成立してしまう場合が少なくない。

Webアプリケーション検査

　このようなWebアプリケーションに対する攻撃を回避するためには、サービスをリリースする前に、脆弱性がないかをチェックする必要がある。検査の手法としては、「BlackBoxテスト」「WhiteBoxテスト」「GlassBoxテスト」の3種類がある。どの手法を用いるかは、Webアプリケーションの用途や重要性に応じて選定を行う。

BlackBoxテスト

　BlackBoxテストは、Webアプリケーションの内部構造がわからない状態で検査を行う方法だ。用意された機能が仕様を満たしているか、外部からテストパターンを送ることによって調べる。

　検査者が知りうる情報は、inputパラメータとそれによるoutputのみである。inputパラメータを変化させ、挙動を調査することでWebアプリケーション内部での情報の扱いを推測し、おかしな挙動をするパターンがないかをチェックする。

　攻撃者の視点からの検査が可能であり、一通りのセキュリティのチェックが行える。検査者はプログラム内部の細かい部分を知る必要がないため、比較的コストをかけずに検査ができる。通常はこの検査が行われることが多い。

WhiteBoxテスト

　WhiteBoxテストでは、Webアプリケーションのソースコードを直接見ることにより、検査を行う。BlackBoxテストとは違い、inputに対する挙動を確実に追えるので、正確かつ効果的な検査を行うことができる。

　ソースコードの中を精査するため、検査者に対して特定の開発言語に対する深い知識を要求する。加えて、通常は開発者と検査者とが別であることが多いため、内部構造を理解する手間がかかるため、多大なコストがかかってしまうのが欠点である。

GlassBoxテスト

　GlassBoxテストは、WhiteBoxテストとBlackBoxテストの両方を行うものである。かなり効果的な検査が行えるが、反対にコストが最もかかってしまう方法でもある。

BlackBoxテストによるWebアプリケーション検査