web methodology

このレポのwikiでホストされている方法論にまっすぐジャンプします。

または、テスト追跡のためにGoogleシートテンプレートをご覧ください。

方法論について

この方法論は、Webアプリケーションのセキュリティ評価を実施する方法に関する意見のガイドを提示します。主な焦点は、セキュリティレビュー中にテスターがカバーすべきすべての主要領域を明確に列挙することです。ツールとして、セキュリティテスターはドキュメントから学習し、それを使用してテストプロセスを形作ることができます。また、開発者は、アプリケーションにどのような脆弱性が存在する可能性があるか、および攻撃のリスクを減らすために実装すべきベストプラクティスを理解することもできます。

あなたが初心者の場合、この方法論は、チュートリアルや紹介というよりも、参照文書と見なされる場合があります。代わりに、PortswiggerのWeb Security AcademyとEric RescorlaのブログシリーズがWebセキュリティモデルを理解することをお勧めします。

方法論の目標

この方法論の目標は、テストする問題、その問題が問題になる理由、および（可能な場合）問題を効率的にテストし、修正する方法に関する推奨事項を提供するのに可能な限り効果的であることです。ドキュメントを書くときに私が従う指針の原則は次のとおりです。

柔軟性、信頼性、ユーザビリティ：ドキュメントは、幅広い異なるアプリケーションで最新の状態に保ち、使用可能な状態に保つ必要があります。方法論が特定のテクノロジーまたはフレームワークに重点を置いている場合、読者は特定の問題が自分の状況に当てはまるかどうかを確認しません。経験の浅い読者（最新のセキュリティテストがどのように見えるかを紹介するため）と高度に経験の浅い読者（最新の状態を維持し、完全なカバレッジを確実に達成できるようにするため）が使用できるはずです。

簡潔：各カテゴリまたは問題を説明する上で、ドキュメントはできるだけ簡潔でなければなりません。問題の中心に直接到達し、詳細については必要に応じて高品質の参照を提供します。 1つの問題がドキュメント全体のほんの一部である場合、単一の問題に関する情報でドキュメントを膨張させないでください。

意見を述べる：ベストプラクティスを明確に述べることを恥ずかしがらないでください。さらに重要なことは、可能なすべてのセキュリティの問題をカバーしようとしないでください。特に、ほとんどの状況で問題が最小限または影響を与えない場合です。問題に一連の許容可能な推奨事項がある場合は、安全で広く適用可能な提案を行い、特定のコンテキストの推奨を調整するために読者に依存します。

最終的に、特定のアプリケーションのコンテキストを考慮に入れることができる経験豊富なテスターの判断に代わる方法論はありません。 Cで記述された自家製の埋め込みHTTPサーバーは、React Frontendを備えた最新のWebフレームワークを使用して、Kubernetesマイクロサービスとは非常に異なる脆弱性を持ちます。このドキュメントでは、Webアプリケーションのセキュリティの改善に関心のある人が使用できるベースラインを定義し、高品質の結果を提供するためにテスターを保持できる標準として機能します。