Webアプリケーション・セキュリティ・テストの包括的なチェックリスト

ステップ2 計画

テスト方式を文書化し、各評価担当者に作業内容とテスト関連の作業に当てることができる期間を確実に周知します。

このタイプのアプリケーションに該当する脆弱性の種類を整理する。

認証を行うアプリケーションの場合、以下のチェック項目が当てはまります（これに限られません）。

• セッション管理
• ブルートフォース（総当たり攻撃）
• 特権エスカレーション
• パスワードの複雑さ

各チームメンバーに個別のロールと資格情報を割り当てる（チームで取り組む場合）。

専門に応じて、機能または脆弱性のタイプ別にチームメンバー間でアプリケーションを分割することをお勧めします。

実行する自動テストの種類を決める。

コンフィグレーションとスキャンの担当者を割り当てます。

「テスト終了」の期限を定め、その時点でテストチームはすべての脆弱性を文書化する。

この時点で報告書を作成することをお勧めします。

内部・外部の状況報告ミーティングを予定する。

内部の状況報告ミーティングは週2回行い、テスト担当者とプロジェクト/顧客担当マネージャーを参加させます。外部の状況報告ミーティングは週1回行い、内部チームと顧客を参加させます。可能であれば、プロジェクトマネージャーがチームの状況をひととおり説明してからチームメンバーに詳細の報告を引き継ぎます。

具体的なテスト・ケースを文書化する。

この作業は顧客からの依頼があった場合にのみ行います。

自動/手動クローリングを実行する。

契約条件に規定されている場合。この作業は実施フェーズで役立ち、調整が必要になった場合にスコープに関する詳細情報を得ることができます。

ステップ3 実施

テストを行って脆弱性を検出します（存在する場合）。

自動テストを実行し、結果をトリアージする。

自動化ツールは慎重に選んでください（最低でも一般的なOWASP Top 10脆弱性に対応していること）。自動テストを利用することにより、テスト担当者は手動解析が必要なビジネスロジックとデータフローにスキルを集中できます。自動テストは、ライセンスを取得して利用している、または内製したツールに応じて組織ごとに若干異なります。

手動テストを実行する。

手動テストは、一般に自動テストでは見落とされているビジネスロジックやデータフローに対応します。手動テストの例を次に示します。

1. テスト担当者は、実際のURL（https://www.example.com/users/edit?id=123456&admin=false）とは少し異なるURLへの管理者権限によるアクセスを発見します。
2. その管理者権限でのアクセスを試みたURLはhttps://www.example.com/users/edit?id=123456&admin=trueに変更されています。
3. 結果に応じて脆弱性を文書化します。テスト担当者は同様のページに移動し、この問題がまだ続いているかどうかを確認します。

ほとんどのツールでは、同じページに複数の要求を送信して異なる応答が返ってくるかどうかを確認します。また、多くのツールでは、HTTP 500エラーが返された場合には脆弱性が存在するとされます。要求とエラーメッセージを確認して脆弱性が実際に生じているかどうかを判断するのはテスト担当者の責任です。

脆弱性が検出された場合は成果物を文書化および収集する。

脆弱性が見つからなかった場合でも、顧客からテスト結果の提出を依頼されることがあります。

ステップ4 報告

結果をすべて文書化し、顧客に報告します。

結果を正式な形にする。

これには説明、インスタンス（影響するURL）、ロール、証拠、再現手順、可能性、影響、対策を含める必要があります。

最終報告書のテクニカルレビューを行う。

これにより一貫性、体裁、テクニカルライティングに不備がないことを確認します。

「報告」ミーティングを行う。

（顧客から依頼された場合）結果をレビューし、話し合いに基づいて適宜調整を行います。