Webアプリ、入力チェックで万事OK？：星野君のWebアプリほのぼの改造計画（3）（2/5 ページ）

ほかのWebアプリケーションもささっと検査してよ

　平野部長からお呼びが掛かった。

平野部長　「Webのプロジェクトを本格始動する前に、セキュリティをちゃんとした方がいいんじゃないかってことになってね。ほら、またSQLインジェクションとかあると困るじゃない」

星野君　「そうですねぇ」

平野部長　「セキュリティ詳しいみたいだからさ、星野君にほかのやつも大丈夫か見てもらうことになったからよろしく」

星野君　「ええっ。僕がですか？？えっと、そんなに詳しくないんですけど……」

平野部長　「まあまあ、謙遜しなくてもいいよ。頼んだからね」

　星野君は、またしても平野部長に一方的に押し切られ、検査対象となっているWebアプリケーションの資料を渡された。それは、現在会社のWeb上で稼働している「お問い合わせ」機能。問い合わせ内容入力画面、入力内容確認画面、そして送信完了画面という構成のよくあるパターンだ。

　「検査する」といっても何をどうしたらいいのか分からない。星野君は、まずWebアプリケーション検査について調べることにした。

　Webアプリケーション検査のタイプには、大きく分けて3つあるらしい。「ブラックボックステスト（Black Box Test）」「ホワイトボックステスト（White Box Test）」「グラスボックステスト（Glass Box Test）」と呼ばれるものだ。

　ブラックボックステストは、Webアプリケーションの内部構造が分からない状態で検査を行う方法、つまりテストをする人がさまざまなアクセスを試みてWebアプリケーションの挙動から問題を判断する方法だ。一方、ホワイトボックステストは、Webアプリケーションのソースコードを直接見ることによりおかしなところがないかを判断する方法だ。グラスボックステストはブラックボックステストとホワイトボックステストの両方を行う。

　星野君は、実際に攻撃者の視点から検査が可能なブラックボックステストをすることにした。何より他人の書いたソースコードを精査するのは大変だし……。

Webアプリケーション検査ツールが必要みたいだ

　きちんとしたWebアプリケーション検査をするためには、検査補助ツールを使いこなさなくてはいけないようだ。まこと先輩にいわれて「Webアプリケーション　検査」でいろいろ調べていたので、検査をするためのツールがいくつか存在しているというところまでは知っていた。Webアプリケーションの挙動をきちんと確認するためには、通常のブラウザでアクセスできる範囲だけじゃなくて、こういったツールを使ってやらないとダメみたいだ。

　星野君が使おうとしている検査補助ツールは、プロキシとして動作し、HTTPリクエストを書き換えるというもの。これらのツールはローカルPCにインストールできる。仕組みとしては図1のようになっている。

図1 検査補助ツールの動作

　通常はWebブラウザから直接Webサーバへリクエストが送信されるのだが、検査ツールを起動するとこのリクエストをインターセプトし、任意に書き換えてWebサーバへと送信することが可能になる。

　例えばポート8080で検査ツールを動作させている場合、Webブラウザのプロキシ設定を「localhost:8080」とするだけで、検査ツールがWebブラウザからのHTTPリクエストをインターセプトする。そして、書き換えられたリクエストを検査ツールがWebサーバに送信するのだ。

　「通信を途中でインターセプトして書き換える」というと結構難しそうだ。取りあえずどれか使ってみようということで、星野君はいくつかある検査ツールの中で「Burp proxy」というツールを選んだ。そして、プロキシ設定を行い、WebブラウザでWebページを閲覧してみた。