一方で、効果的なツールを使って診断を自動化したり、社内で内製化したいというニーズは社会的に高まっている。AppScanは、どの程度この需要に応えることができるだろうか。今回筆者は、日本IBM社の協力を得て、そんな筆者の疑問を検証する機会を得たので、詳しくレポートすることにする。長文ご容赦願いたい。
●5,000種類以上のテストケース
次にテストポリシーを指定する。約5,000種類あるテストケースは、全てオンとオフを選べるようになっているが、通常、定義済みポリシーを使うことを推奨されていた。
 |
デフォルトとなっているテストは、安全ではないものを除くすべてのテスト項目である。バッファオーバフロー等のシステム自体をダウンさせる危険性のあるテストは、安全でないテストとしてデフォルトからは省かれている。
また、稼働中のシステムに向けてSQLインジェクションのテストとしてアプリケーションが動作してしまうようなテストケースが含まれているが、自動化されたツールで脆弱性を検出するためには致し方ないことだろう。診断自体はできればプロダクションサイドではないところで実施することが望ましいだろう。また、診断対象のアプリケーションに、メール送信機能などがある場合、大量に送信されエラーメールが返信されたりする場合もあるので、本番環境での使用は注意が必要である。
●アプリケーションのインフラも診断可能
診断では、Webアプリケーションのテストと、そのアプリを載せているインフラストラクチャのテストを行うことができる。インフラストラクチャとは、WebサーバやSQLサーバ、あるいはPHPのライブラリなどを指している。例えば、古いApacheのバージョンを使っていて、XSSの問題が残っていたりする場合、問題点として指摘してくれるようだ。本番系に近いテストならインフラも同時に実施すればいいだろう。
実際に診断を開始すると、診断は2つのフェーズに分かれる。第一段階として、まずリンクをたどって、どのページにどの判定をするかをクロールして決定する。これは長くても数分で終わるようだ。そしてその後、実際の診断を行う。
実際にデモ診断を行ってみたが、日本IBM社の担当氏と一緒にAppScanに触れた筆者でも、特に疑問は無かった。この平易さであれば、個人差があるのは当然だが、開発者が使ったり、社内で脆弱性診断の実施習慣を広げていくことも充分できるように感じた。
平易に使えるとはいえ「Webアプリケーションを一通り診断させるための通し方」には、工夫が必要とされる場合もあるようだ。たとえばセッションIDの変化でログイン済みかどうかを追いにくい場合には、ログイン後に必ず現れる画面内の文字（たとえば、「ログアウト」という文字など）を設定することで、セッションが維持されているかどうかを認識させるための設定を行う必要がある。しかし、一度設定できてしまえば後は誰がやっても同じになる。
●診断結果の表示
診断結果が出ると、重要度「高」の問題が赤く表示される(重要度は、「高」「中」「低」「情報」の4段階)。診断結果から、たとえば「SQLインジェクション」という問題をクリックすると、どのURLの、どのパラメータがSQLインジェクションが起こるのかを表示してくれる。また、画面下部には、SQLインジェクションとはそもそも何なのか、推奨される修正はどういうものなのか(たとえばストアドプロシージャの書き方等)を提案してくる。
 |
 |
また「要求応答」をクリックすると、テストケースとレスポンスが表示され、レスポンスとして問題視されているところはハイライトで記載される。
 |
「ブラウザで表示」をクリックするとブラウザで実際にこのレスポンスをレンダリングしてスクリーンショットとして保存、レポートに添付することができる。なおAppScanは、IEライクなブラウザを自ら持っている。IEのコンポーネントは使っていないものの、ブラウザによってアプリケーションの動きが変わるような場合、AppScanをプロキシとして機能させて、IEによる診断を行うこともできるそうだ。
●誤検知について
AppScanは、パターンしか見えていないので、当然誤検知は存在する。たとえば、SQLサーバのエラーメッセージを問題点と判断したりする。ただし、取材協力の日本IBM社によれば、誤検知が大量に出ることは無いそうだ。いずれにしても指摘された問題は開発者が一個ずつ確認することになるので、誤検知の問題はそれほど大きくないはずだ。(つづく)
Rational AppScan
（取材協力：日本アイ・ビー・エム株式会社／執筆：上野 宣）
