ソフトウェア・インテグリティ

 

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

アプリケーション・レベルの攻撃の最も一般的な標的がWebであることをご存知でしたか?しかも、何らかの理由でWebアプリケーションのセキュリティに関わる作業に携わった経験がある方は、その実現が容易でないこともご存知でしょう。アプリケーション・セキュリティを実現するには、戦略的アプローチをとることが重要です。このWebアプリケーション・セキュリティ・テスト・チェックリストは、テスト手順を理解し、テストの主要な要素を把握して見落としを防ぐためのガイドです。

以下の6つのステップに従ってアプローチをカスタマイズし、最大限に効果的、効率的、かつ迅速なテスト方式を実現しましょう。

 

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

 

ステップ1 情報収集

アプリケーションの計画およびテストを適切に行うためにそれに適した質問をします。

アプリケーションの問題箇所を特定する。

これにはユーザーがコンテンツを追加、変更、削除できる部分が含まれます。これに該当する箇所では、入力のサニタイジングと出力のエンコーディングを検証する必要があります。

例:ブログの投稿のようにユーザーが大量のデータを入力できるアプリケーションの場合(特にHTMLエディタを利用する場合)、適切な予防メカニズムを設けないとインジェクション攻撃のリスクが高くなります。

ビジネス・ロジックとデータフローを構築する。

これはバイパス、エスカレーション、重要データの漏えいの手法に特化して手動テストが必要な部分などが対象になります。ビジネス・ロジックフローは、データフローごとに、またアプリケーションに対して一意となるように定義することができます。この種の機能は自動解析では見落とされることが多くあります。

例:承認ワークフローや特権アカウントによるアクセスを伴う機能を含めることができます。テスト担当者は以下のことを確認する必要があります。

  • ワークフローのインテグリティ
  • ユーザーが各ステップをバイパスまたはスキップできないこと
  • ユーザーが認可なしには特権アクティビティを実行できないこと

アクセス権/ロール構造を周知する。それぞれについて2つずつ資格情報を収集する。

この手順は、ロックアウトや複数のチーム・メンバーがアクセスする場合に必要です。


 

ステップ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)、ロール、証拠、再現手順、可能性、影響、対策を含める必要があります。

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

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

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

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


 

ステップ5 対策

テストで検出された脆弱性に対処します。

報告書の対策ガイドラインに従って対処する。

具体的な対策作業を開発者に割り当てるのはアプリケーション所有者の役割です。コードのすべての類似箇所に修正を適用することが重要です。ブラックボックス・テストは網羅的なものではなく、同様の問題が存在する可能性があります。


 

ステップ6 検証

テストで見つかった脆弱性が解決され、修正を回避できないようになっていることを確認します。

アプリケーションを再度レビューする。

以前に発見された具体的な問題を探します。

修正によって同じ脆弱性に対する「変種の」試みが阻止されることを確認する。

XSSフィルタ回避手法を実行し、さまざまなロールでエスカレーション攻撃を試行し、別のURLへのリダイレクトを行います。

 

数百人のセキュリティ・エキスパートと優れたテスト・ツールにオンデマンドでアクセスできるシノプシスのマネージド・アプリケーション・セキュリティ・テスト・サービスをご活用ください。