web methodology

Прыгайте прямо на методологию, размещенную в вики этой репо.

В качестве альтернативы, проверьте шаблон Google Sheets для отслеживания тестирования.

О методологии

Эта методология представляет собой самоуверенное руководство о том, как провести оценку безопасности веб -приложений. Основное внимание уделяется четкому перечислению всех основных областей, которые должен покрывать тестер во время обзора безопасности. В качестве инструмента тестеры безопасности могут учиться на документе и использовать его для формирования процесса тестирования. Он также может использоваться разработчиками для понимания того, какие типы уязвимостей могут существовать в их приложениях и лучших методов, которые они должны реализовать, чтобы снизить риск атак.

Если вы новичок, эта методология может считаться скорее справочным документом, а не учебником или введением. Вместо этого я рекомендую Академию веб -безопасности Portswigger и серию блогов Эрика Rescorla , понимая модель веб -безопасности .

Цели методологии

Цель этой методологии состоит в том, чтобы быть максимально эффективной в сообщении о том, какие проблемы для проверки, почему эта проблема имеет значение и (где это возможно) предоставить рекомендации о том, как эффективно проверить и исправить эту проблему. Руководящие принципы, за которыми я следую при написании документа:

Гибкость, надежность, удобство использования : документ должен быть обновлен и доступен для использования в широком диапазоне различных приложений. Если методология слишком сильно фокусируется на конкретных технологиях или рамках, читатели не будут уверены, применяется ли заданная проблема к их ситуации. Это должно быть использовано менее опытными читателями (чтобы представить введение в то, как выглядит современное тестирование безопасности) и читателей с высокой оценкой (для того, чтобы держать их в курсе и помочь обеспечить полное покрытие).

Будьте лаконичными : документ должен быть как можно более лаконичным при объяснении каждой категории или проблемы. Получите прямо в центр вопроса и предоставьте высококачественные ссылки, когда это необходимо, чтобы получить дополнительную информацию. Избегайте вздутия документа с информацией по любой проблеме, когда одна проблема представляет собой лишь небольшую часть всего документа.

Будьте самоуверенными : не уклоняйтесь от четкого заявления о лучших практиках. Еще более важно, не пытайтесь покрыть каждую возможную проблему безопасности, особенно когда проблема оказывает минимальное влияние или нет в большинстве ситуаций. Если проблема имеет ряд приемлемых рекомендаций, сделайте безопасное, широко применяемое предложение и полагайтесь на читателя, чтобы настроить рекомендацию для их конкретного контекста.

В конечном счете, ни одна методология не является заменой суждения опытного тестера, который может учитывать контекст их конкретного приложения. Встроенный домашний сервер HTTP, записанный в C, будет иметь очень разные уязвимости, чем микросервис Kubernetes, используя последнюю веб-структуру с фронталом React. Этот документ определяет базовую линию, которая может использоваться всеми, кто заинтересован в повышении безопасности веб-приложений, и служит стандартом, который тестировщики могут придерживаться, чтобы обеспечить высококачественные результаты.