Собираемся заказать пентест веб-приложения, но хотим подготовиться — есть ли чеклист для самостоятельной проверки?

В прошлом году отдавали 5.000 фунтов за аудит похожего B2B-софта. Сами заранее ничего не проверили, в итоге из 22 пунктов в отчете 14 оказались отсутствующими заголовками HTTP и дефолтными ответами сервера. Было ужасно обидно понимать, что тысячи полторы фунтов из гонорара ушли на описание этой ерунды.

Самое важное — стабильность тестового окружения. Ни в коем случае не пускайте их на прод, поднимите отдельный стейджинг с анонимизированной копией боевой базы. Когда тестировщик начнет слать пейлоады, способные уронить базу или забить очереди, реальные бизнес-процессы не должны встать. И на время теста наложите строгий мораторий на любые деплои.

Проверьте валидацию входных данных и работу с сессиями. Пройдитесь по экранированию спецсимволов во всех формах и параметрах URL. Убедитесь, что пользовательский ввод корректно фильтруется перед записью в БД, а токены сессии гарантированно инвалидируются на бэкенде при логауте. Наличие таких дыр сразу испортит общую картину.

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

Выдайте аудиторам минимум по два валидных аккаунта с разными уровнями прав: двух обычных пользователей и двух администраторов. Плюс еще один демо-аккаунт с максимально урезанными правами. Так они с первых же минут смогут спокойно тестировать горизонтальное и вертикальное повышение привилегий.

А какой формат тестирования согласован — white-box или black-box? Если отдаете исходники и схемы API, то при подготовке первым делом приведите в порядок документацию. Если же доступа к коду не будет, бросьте все силы на аудит внешних эндпоинтов.

Абсолютно правильный подход. Самостоятельная подготовка к тому же здорово прокачивает понимание безопасности внутри команды. Соберитесь на полдня на внутренний воркшоп, пройдитесь по коду с оглядкой на OWASP Top 10 — и выхлоп от внешнего аудита будет максимальным.

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

Согласен.

У меня было наоборот, поэтому и пишу. Решения, работающие в малом масштабе, рушатся при росте я узнал это слишком поздно.

Чем сложнее отменить решение, тем медленнее его принимайте. Проверено опытом.

Если пойдете этим путем, сразу решите вот этот вопрос. Процесс, по которому не ведется учет, не улучшается, потому что вы не знаете, что именно улучшать.

Это мое мнение, не утверждаю, что оно единственно верное.

Позвольте подвести итог сказанному выше. Автоматический отчет о сканировании и пентест — это не одно и то же.

Удачи.

Эта тема в архиве.

У нас было так. Если не зафиксировать это письменно с самого начала, потом возникнут споры.

Забытые тестовые среды становятся входом в систему чаще чем продакшн. ну если напишете результат здесь это поможет и другим.

Я думаю иначе. Без измерений мы всегда приходим к одному и тому же.

Непроверенная резервная копия — не резервная копия. Пишите, если есть вопросы, отвечу по мере возможности.

У меня нет опыта в пентест веб-приложения, поэтому и спрашиваю. Доступность резервной копии в той же сети и под той же учетной записью делает ее частью цели атаки.

Пишите если есть вопросы, отвечу по мере возможности.

Очень актуальная тема.

Вопрос будет немного наивным, извините заранее. Большинство инцидентов начинается не с уязвимости, а с украденного пароля.