Тестирование на проникновение веб-приложений
Автоматические сканеры находят уязвимости, которые находит любой сканер. А недостатки, которые действительно эксплуатируют - нарушенная авторизация, цепочки злоупотреблений бизнес-логикой, неочевидные обходы аутентификации - требуют человека, читающего ваше приложение так, как его читает злоумышленник. Именно это и даёт этот проект.
Что входит
- Покрытие OWASP Top 10
- Тестирование аутентификации & сессий
- Тестирование авторизации / IDOR по всем ролям
- Бизнес-логика & злоупотребление рабочими процессами
- Тестирование API REST / GraphQL
- Тестирование инъекций, SSRF, XXE и загрузки файлов
Результаты
- Резюме для руководства
- Технический отчёт с находками, оценёнными по CVSS
- Шаги воспроизведения & доказательства в виде скриншотов
- Приоритизированный план устранения
- Живой разбор с вашей командой
- Письмо-подтверждение для аудиторов и клиентов, по запросу
- Подтверждение устранения после повторной проверки, отдельным документом
Сроки
3-5 рабочих дней, в зависимости от числа ролей и количества конечных точек. Точные сроки подтверждаются в письменном предложении до начала тестирования.
Где останавливаются сканеры и начинается ручная работа
Сканер найдёт отражённый XSS и устаревшие библиотеки. Он не найдёт, что эндпоинт удаления комментария проверяет идентификатор комментария, но не проверяет, принадлежит ли комментарий запрашивающему пользователю, или что смена параметра роли посреди оформления заказа пропускает шаг проверки платежа. Именно такие находки и эксплуатируют на практике, и они всплывают только тогда, когда специалист читает реальное поведение приложения, а не сопоставляет известные сигнатуры.
Тестирование как минимум охватывает все категории OWASP Top 10, а затем углубляется в то, как устроено именно ваше приложение: его роли и модель прав, его многошаговые процессы и его API-контракты. Если в приложении есть роль администратора, биллинговый процесс или загрузка файлов, им уделяется отдельное внимание - обычно самые значимые находки именно там.
Методика
Тестирование с аутентификацией по каждой роли, определённой в вашем приложении: Burp Suite для перехвата и ручной анализ для логики. Покрытие включает классы инъекций (SQLi, инъекция команд, SSTI), аутентификацию и управление сессиями, контроль доступа на уровне интерфейса и API, SSRF и XXE там, где обрабатываются файлы или URL, и злоупотребление загрузкой файлов, где это уместно. Каждая находка проверяется вручную до того, как попадёт в отчёт - неподтверждённый вывод сканера в ваш отчёт не попадает. Мои опубликованные справочник по эксплуатации веб-приложений и методика разведки отражают те же приёмы, что применяются здесь.
Чего тестирование не делает
Никакого тестирования на отказ в обслуживании, никаких разрушительных действий с боевыми данными и никакой социальной инженерии, если она явно не включена в объём работ. Всё, что создаёт риск для доступности или целостности данных, предварительно согласуется с вами в рамках подписанных правил проведения работ.
Вопросы о тестировании веб-приложений
OWASP Top 10 как база - инъекции, нарушенный контроль доступа, ошибки аутентификации, небезопасная конфигурация, SSRF и так далее - плюс ручное тестирование ошибок бизнес-логики, которые автоматические сканеры найти не могут: нарушенные процессы, пробелы в авторизации в духе IDOR, манипуляции ценой или количеством и злоупотребление многошаговыми процессами, специфичными для того, как ваше приложение действительно работает.
Да. Большинство современных приложений построено вокруг API, и именно там обычно находятся интересные находки: отсутствующая авторизация на уровне объектов, массовое присвоение, пробелы в ограничении частоты запросов и проблемы с обработкой JWT. Если у вас есть REST или GraphQL API, он тестируется вместе с фронтендом, а не в последнюю очередь.
Ручное тестирование, в котором автоматические инструменты (Burp Suite и другие) ускоряют покрытие, но не заменяют суждение. Ошибки бизнес-логики, обходы авторизации и цепочки уязвимостей находит человек, читающий реальное поведение приложения, а не сканер, сопоставляющий сигнатуры.
От 3 до 5 рабочих дней для типового приложения, в зависимости от числа ролей, процессов и конечных точек API в объёме работ. Более крупные приложения с несколькими ролями пользователей или сложными моделями прав занимают больше времени - точные сроки подтверждаются в письменном предложении.
Да, и часто это предпочтительнее: тестовая среда снимает любой риск для реальных клиентских данных и при этом позволяет проверить настоящую логику приложения - при условии, что она точно повторяет боевую. Тестирование в боевой среде тоже допустимо в согласованном окне по правилам проведения работ.
Тесты веб-приложений начинаются от 500 $ и зависят от числа ролей, процессов и конечных точек в приложении. Письменную фиксированную цену вы получаете до начала тестирования - подробности на странице цен.
Узнайте первыми, что нашёл бы настоящий злоумышленник
Бесплатное обсуждение объёма работ, предложение с фиксированной ценой в течение 24 часов.