Что такое пентест и как проводится тестирование на проникновение
Основы4 минРедакция Innovialabs
Коротко
Пентест — это разрешённая имитация атаки: специалисты пытаются взломать вашу систему в согласованных границах и отдают отчёт с доказанными уязвимостями, их последствиями и способами исправления.
Короткий ответ
Пентест (тестирование на проникновение) — это контролируемая атака на ваш сайт, приложение, API или сеть, которая проводится с вашего письменного согласия. В отличие от автоматического сканирования, пентестер не останавливается на «здесь, возможно, уязвимость» — он пытается реально её эксплуатировать, связать несколько мелких проблем в настоящую атаку и показать, до чего доберётся злоумышленник: данные клиентов, админка, платежи, серверы.
Итог — не взломанная система, а отчёт: что найдено, как доказано, насколько опасно и что исправить.
Black, grey и white box
Подход зависит от того, сколько тестировщики знают о системе на старте.
| Подход | Что получают тестировщики | Кого имитирует | Сильные стороны | Ограничения |
|---|---|---|---|---|
| Black box | Только домен или название приложения | Внешнего атакующего | Реалистичный взгляд «из интернета» | Много времени уходит на разведку, глубокая логика может остаться непроверенной |
| Grey box | Учётные записи для каждой роли, базовая документация, описание API | Зарегистрированного пользователя или партнёра | Лучший баланс глубины и реализма для большинства веб- и мобильных проектов | Требует подготовки с вашей стороны |
| White box | Исходный код, архитектура, конфиги, админ-доступ | Инсайдера или очень настойчивого атакующего | Больше всего находок за день работы | Наименее реалистичен как сценарий атаки |
Для типичного продукта с авторизацией и ролями чаще всего полезнее grey box: ошибки разграничения доступа между пользователями — одни из самых частых серьёзных находок, а без учётных записей до них сложно добраться.
Этапы пентеста
- Согласование scope и правил — что тестируем, как, когда и кому звонить.
- Разведка — поддомены, открытые порты, технологии, публичный код, утёкшие данные.
- Поиск уязвимостей — автоматические инструменты плюс ручная проверка логики, ролей и потоков данных.
- Эксплуатация — подтверждение уязвимостей безопасным использованием, часто в цепочке из нескольких мелких находок.
- Оценка последствий — как далеко может зайти атакующий: чужие данные, повышение привилегий, доступ к инфраструктуре.
- Отчёт — описание всех находок с доказательствами и рекомендациями.
- Ретест — после ваших исправлений команда проверяет, что уязвимости действительно закрыты.
Scope и правила проведения
Этот документ защищает обе стороны. В нём должно быть чётко указано:
- Что входит в scope: конкретные домены, диапазоны IP, версии приложений, эндпоинты API.
- Что не входит: сторонние сервисы, платёжные провайдеры, чужой shared-хостинг.
- Разрешённые техники: например, без DoS и без социальной инженерии сотрудников, если это не оговорено отдельно.
- Временные окна и среда: staging, production или обе.
- Работа с данными: что можно выгружать, как хранятся доказательства и когда удаляются.
- Контакты с обеих сторон и порядок остановки, если что-то сломалось.
- Письменное разрешение от человека, который действительно вправе разрешить тестирование этих систем.
Что вы получаете в итоге
- Резюме для руководства простым языком.
- Список находок: у каждой уровень критичности (часто по CVSS), затронутый компонент, шаги воспроизведения и доказательства.
- Рекомендации по исправлению каждой проблемы и её первопричины.
- После ретеста — обновлённый отчёт или письмо о том, какие находки закрыты.
Как подготовиться
- Определите цель: проверка перед запуском, требование клиента или инвестора, комплаенс, беспокойство после инцидента.
- Выберите среду. Staging, повторяющий production, безопаснее; production реалистичнее. Если тестируете production — договоритесь об ограничениях.
- Сделайте свежие бэкапы и проверьте, что они восстанавливаются.
- Создайте тестовые аккаунты для всех ролей с правдоподобными тестовыми данными вместо реальных клиентских.
- Проверьте правила хостинга или облака насчёт тестирования безопасности и решите, нужно ли пропускать IP тестировщиков мимо WAF.
- Заморозьте или фиксируйте деплои на время теста, чтобы находки не терялись между версиями.
- Заранее выделите время разработчиков на исправления — пентест без исправлений лишь документирует риск.
Частые ошибки
- Заказывать пентест сырого продукта, который через месяц полностью изменится.
- Включать в scope только лендинг, хотя реальные данные живут в API и мобильном приложении.
- Считать дешёвое автоматическое сканирование пентестом.
- Закрывать находки по одной, не устраняя причину, например отсутствие проверок доступа во всём API.