第5回 テストを設計するには（その3）：理論的・計画的なWebアプリケーションのテストの実現（2/2 ページ）

[加藤大受，ITmedia]

強制ブラウジング

　強制ブラウジングとはURLを直接入力することで、本来非公開を想定しているエリアのファイルやディレクトリの閲覧が可能になってしまうことを指す。これらの問題が発生するのは単純なWebサーバの設定ミスであることが多い。しかし、この問題によりWebサーバ上におかれているデータベースファイルなどへの不正アクセスが可能になってしまう。強制ブラウジングの検証としては、次のような項目がある。

• ディレクトリインデックスが表示されないか
• システム要件で指定されているディレクトリ以外アクセスできないかどうか
• Webサーバに標準に付属しているサンプルなどが実行できないかどうか

　これらの項目はApacheのhttpd.confや運用サーバのファイルリストをレビューすることで問題を発見できる。設定ファイルをレビューした後、ビジネスリスクの高いURLを直接入力しアクセスできないことを確認しておく必要があるだろう。また、設計レビュー時に、推測しやすいパスやcgi-binなどの一般的に利用されることが多いパス以下に重要なファイルを置いていないことを確認することも大切である。

Cookie／URLパラメータの改ざん・詐称

　パラメータの改ざんとはGETパラメータおよびPOST時に送信されるパラメータを変更して不正アクセスを行うことである。特にGETパラメータの改ざんはブラウザに表示されている以下のようなURLに対して、useridまたはgroupidという変数に異なる値を設定して簡単にアクセスが可能になるので注意が必要である。

http://www.mytest.com/cgi-bin/mytrip.cgi?userid=1&groupid=2

　このケースの場合、useridの値を適当に変更して別のユーザでアクセスできてしまう可能性がある。

　URLパラメータの改ざんを検証するには設計のレビューのほか、URLを直接入力してみて改ざんができないことを確認する。POST処理の場合、特にHiddenとなっている変数に含まれる値に価格などの重要な項目が入っていないことをレビュー時に確認し、この値を変更してPOST処理をした場合の動作を確認する必要がある。

　Cookieについても同様である。Cookieを利用しているWebアプリケーションの場合、利用しているCookieの有効期限とCookieに設定されている内容を設計時にレビューする必要がある。また、Cookieのファイルを直接開き、値を変更して再度アクセスしてみるなどの試験を行う必要がある。

　Cookie／URLパラメータの改ざんについては設計時のレビューによって不具合を発見するのが一番である。セキュリティ試験を行うことは重要だが、この改ざん問題については試験実施に見つかった場合大きな設計の変更が必要となることが多いのでより上位のフェーズで不具合がないことを確認してほしい。

バッファーオーバーフロー

　バッファオーバーフロー問題はC/C++を利用したシステムで起こる問題である。具体的にはプログラムが確保しているバッファサイズよりも大きなデータを送信して、バッファ領域を書きつぶし、戻り先のアドレスに悪意のあるコードのアドレスを指定することで、サーバ内の情報の取得や改ざん、システムの強制シャットダウン、踏み台として外部サーバへのアクセスを行うことである。

　この問題は内部コードに精通していなければ検証できないため、テストエンジニアが検証するのは非常に難しい。バッファーオーバーフローの問題は一般的に文字列を扱う関数などで発生することが多いので、C/C++言語を利用するときはこれらの関数を利用しているコードが動的にバッファを取得しているかどうかを精査するしかないだろう。

　テストエンジニアとしては最低限として、利用するOS、ミドルウェア、Webサーバにバッファーオーバーフローの問題が発見されているバージョンではないかを確認して頂きたい。

SQLインジェクション

　SQLインジェクションはHTMLフォームやURLに悪意のあるSQL文やその一部を入力し、データベースへの不正操作を行うものである。一番単純なケースとしてはパスワードの入力欄に【'OR 'A'='A】などという文字列を設定し、パスワードが分からなくてもログインしてしまう方法である。この問題が発生するのはHTMLフォームのユーザIDとパスワードのテキストボックスの値から単純に以下のようなSQL文を生成しているケースなどである。

SELECT * FROM users WHERE userid= '<ユーザIDの値>' AND user_pass='<パスワードの値>'

　このようなSQLインジェクションが発生しないようにするにはHTMLフォームの入力値から単純にSQL文の生成を行わないようにすることである。同様にURLパラメータでもこのHTMLフォームと同じような仕組みで不正アクセス可能なので、設計時にSQLインジェクションが起きないかどうかをレビューする必要があるだろう。また、セキュリティ試験時にパスワード欄、GET処理のパスワードに関連するURLパラメータの検証を行う必要がある。

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

　クロスサイトスクリプティングはクラッカーによって埋め込まれた任意のJavaScriptsやVBScriptsなどのスクリプトが実行されて起きる問題である。よくあるケースとしては掲示板やゲストブックなどのHTMLフォーム内でHTMLタグが利用できるようになっているケースで、タグの埋め込みによって発生するものである。

　これを防ぐには、HTMLフォームにてHTMLタグの利用を許可しないことやタグのチェックを行うようにすることである。これらの内容も設計フェーズのレビューで検証できる。また、セキュリティ試験の実施時に実際にタグを埋め込んで検証してみるのもいいだろう。

　Webアプリケーションの脆弱性の問題が発生する原因としては、Webアプリケーションの設計ミス・開発ミス、Webサーバの設定ミス、OSやミドルウェアのセキュリティホールなどである。ほとんどの問題は設計フェーズのレビューで発見できるだろう。また、テスト計画書の作成のタイミングで、ほかの試験と同様にどのレベルまでセキュリティ試験を行うのかを決定する必要があるだろう。その際に脆弱性の問題が発生した場合のビジネスリスクについてもセキュリティ試験の計画書の中で明確にしておき、試験コストの必要性を明確にしておくことをお勧めしたい。

　ここではセキュリティ試験というテスト項目が存在し、その重要性の解説だけにとどめておく。ビジネスリスクを考慮した試験計画の考え方については本連載にて再度詳しく説明していく予定である。

次回に向けて

　再帰テスト、総合テストを除き、一般的なテスト項目については今回までで紹介した。次回はドキュメント試験、ユーザビリティ検証、信頼性試験、強制エラー試験など、その他のテスト項目について紹介していく。