Методология пентеста
Пентест без методологии — это везение: находишь то, на что случайно ткнул. PTES и OWASP WSTG превращают его в покрытие, которое можно доказать, scope, который можно защитить, и отчёт, по которому защитник реально может действовать.
Два тестировщика получают один и тот же недельный проект против одного и того же веб-приложения. Первый открывает Burp, кликает по тем частям, что выглядят интересными, на второй день находит хранимую XSS, остаток недели гоняет её и сдаёт отчёт с одной находкой. Второй работает по чек-листу: каждый путь аутентификации, каждая граница контроля доступа, каждый ввод, пересекающий границу доверия, обработка сессий, загрузка файлов, сброс пароля, админ-API, на который интерфейс нигде не ссылается. Те же часы, те же инструменты — но второй находит XSS и IDOR на эндпоинте инвойсов, отсутствие rate limit на сбросе и забытый staging-поддомен, отдающий отладочные стектрейсы. Дело не в таланте. Первый нашёл то, на что случайно посмотрел; второй протестировал приложение. Этот разрыв — везение против покрытия — и закрывает методология, и это вся причина, по которой клиент платит за пентест, а не за удачный вечер.
К концу урока ты поймёшь, почему воспроизводимая методология (PTES, OWASP WSTG) превращает тестирование в доказуемое покрытие, как фазы сцеплены друг с другом и где до всего этого стоят scope и авторизация.
Прежде всего: авторизация и scope
Всё в этом уроке предполагает, что сначала существует один документ: подписанная авторизация с явным scope. Пентест механически — это делать с системой то, что сделал бы атакующий, и единственное, что отделяет оплаченный проект от уголовной статьи, — письменное разрешение от того, у кого есть полномочия его дать. Практикуйся на лабораторных мишенях, CTF, своей инфраструктуре или системах, на тестирование которых у тебя есть явная, письменная авторизация. Больше ни на чём.
Scope — это не бумажка, которую пробегаешь глазами. Это контракт, определяющий, что вообще значит покрытие. Scope говорит, какие хосты, домены, диапазоны IP и поверхности приложения в границах; что явно вне (общий SSO-провайдер, платёжный процессор, которым ты не владеешь, сторонний CDN); окно тестирования; правила взаимодействия (разрешена ли социальная инженерия? отказ в обслуживании? тестирование в продакшене или только на staging?); и аварийный контакт на случай, когда что-то сломается в 02:00. Зрелый рефлекс: если этого нет в scope — ты не трогаешь это, а если радиус поражения находки выходит за scope — останавливаешься и звонишь по контакту. В PTES это фаза Pre-engagement Interactions, и именно она держит тебя вне тюрьмы и сохраняет несвязанные системы клиента целыми.
Что методология реально даёт
Доминируют два фреймворка. PTES (Penetration Testing Execution Standard) задаёт форму проекта от начала до конца — семь фаз от pre-engagement до отчёта. OWASP WSTG (Web Security Testing Guide) — это глубина для веб-приложенческого среза: чек-лист конкретных тест-кейсов (аутентификация, управление сессиями, контроль доступа, валидация ввода, бизнес-логика, клиентская сторона), у каждого стабильный ID вроде WSTG-ATHN-03, чтобы находка отображалась на именованный, воспроизводимый тест. Их используют вместе: PTES — для хода всей работы, WSTG — чтобы веб-фаза была исчерпывающей, а не «по ощущениям».
Ценность — это три вещи, которые волнуют зрелого инженера. Первое, покрытие, которое можно доказать: когда клиент спрашивает «вы тестировали сброс пароля?», ответ — ID кейса WSTG и результат, а не «вроде да». Второе, воспроизводимость: другой тестировщик или тот же тестировщик через квартал прогоняет тот же чек-лист, и результаты сравнимы — видно, что изменилось. Третье, защитимый отчёт: каждая находка прослеживается к именованному тесту, воспроизведению и оценке риска, так что команда разработки может действовать, а не спорить, реально ли это. Методология превращает интуицию тестировщика в аудируемый процесс — именно это меняет «нам повезло» на «у нас есть покрытие».
Фазы, и почему порядок несущий
Фазы — не бюрократия: каждая существует потому, что пропуск делает следующую поверхностной или неверной.
| Фаза PTES | Что делаешь | Пропустишь — и… |
|---|---|---|
| Pre-engagement | Scope, правила взаимодействия, подписанная авторизация | Тестируешь системы вне границ — незаконно и вне scope |
| Сбор разведданных | Карта реальной поверхности атаки: поддомены, эндпоинты, стек | Тестируешь главную и упускаешь забытый staging-API |
| Моделирование угроз | Решаешь, чего атакующий реально хочет здесь; приоритизируешь | Тратишь неделю на мелкие баги, упускаешь самое ценное |
| Анализ уязвимостей | Прогон чек-листа WSTG по каждой поверхности и границе доверия | Покрытие становится «на что ткнул» — везение, не тестирование |
| Эксплуатация | Подтверждаешь, что находка реальна и достижима, а не теория | Отчёт полон неподтверждённого «потенциального» шума, его игнорируют |
| Пост-эксплуатация | Показываешь реальное воздействие и охват — в scope и правилах | Клиент не оценит риск: «ну получил ты один шелл, и что?» |
| Отчёт | Находки, воспроизведения, оценки риска, рекомендации | Вся работа выше бесполезна — по ней никто не может действовать |
Порядок несущий, потому что каждая фаза — вход для следующей. Сбор разведданных до анализа уязвимостей — это то, что вскрывает staging-поддомен, который иначе ты бы никогда не протестировал. Моделирование угроз до эксплуатации — то, что не даёт тебе сжечь неделю на self-XSS, пока неаутентифицированный админ-API стоит нетронутым. А отчёт — не запоздалая мысль: для клиента отчёт и есть продукт. Блестящая находка, которую никто не может воспроизвести, оценить или починить, стоит ровно столько же, сколько отсутствие находки.
▸Почему это работает
Зачем вообще идти по чек-листу — разве это не делает тестирование механическим, и разве креативный атакующий не обыграет того, кто идёт по списку? Чек-лист не замена креативности; он — пол под ней. WSTG гарантирует, что ты покрываешь известные классы — каждый путь аутентификации, каждую границу контроля доступа, — так что твоя дефицитная креативная энергия уходит на изъяны бизнес-логики и цепочки эксплойтов, которые ни один чек-лист не перечислит, а не на повторное открытие того, что ты забыл протестировать фиксацию сессии. Зрелый инженер прогоняет чек-лист, чтобы дёшево забрать рутинное покрытие, а затем тратит освободившееся время там, где интуиция реально окупается. Пропуск чек-листа не делает тебя креативнее; он заставляет тебя забыть скучный баг, который оказывается пробоем.
Как это ведёт зрелый инженер
Методология — рамка, а не клетка. Зрелый инженер берёт PTES как хребет — scope первым, отчёт всегда — а WSTG как реестр покрытия: каждый кейс отмечен как проверен, пройден или помечен, так что в конце «что мы тестировали?» имеет буквальный ответ. Суждение живёт в моделировании угроз и распределении глубины: прогоняешь полный чек-лист, чтобы дёшево забрать покрытие, затем концентрируешь оставшиеся часы на поверхностях, которые модель угроз называет самыми важными, — денежные потоки, границы аутентификации, админ-пути. Покрытие — из чек-листа; глубина — из суждения. Эта комбинация и заставляет второго тестировщика из вступления обыгрывать первого каждый раз, независимо от того, кому в ту неделю больше повезло.
У тебя авторизованный недельный веб-проект. На второй день находишь сочную хранимую XSS. Каков зрелый ход на остаток недели?
Какой единственный важнейший артефакт должен существовать до начала любого тестирования?
Тестировщик подтверждает один критический баг и пишет отчёт только с этой находкой, протестировав лишь поверхности рядом с ней. Почему методология зовёт это провалом, хотя баг реален?
Расставь ранние фазы PTES в порядке, в котором они должны идти, от первой к последней:
- 1 Pre-engagement (scope + подписанная авторизация)
- 2 Сбор разведданных (карта реальной поверхности атаки)
- 3 Моделирование угроз (решить, чего хочет атакующий)
- 4 Анализ уязвимостей (прогон чек-листа WSTG)
- 5 Эксплуатация (подтвердить, что находка реальна)
- 01Объясни, как PTES и OWASP WSTG сочетаются и что даёт каждый.
- 02Почему порядок фаз PTES несущий и почему scope — фаза, гейтящая всё?
Пентест без методологии — везение: находишь то, на что случайно посмотрел. Методология превращает его в доказуемое покрытие. Всё начинается с pre-engagement — подписанной авторизации и явного, письменного scope от того, у кого есть полномочия его дать; этот документ — и то, что держит работу законной, и определение того, что значит покрытие, и ты никогда не трогаешь ничего вне его. PTES даёт семифазный хребет: pre-engagement, сбор разведданных, моделирование угроз, анализ уязвимостей, эксплуатация, пост-эксплуатация, отчёт — и порядок несущий, потому что каждая фаза питает следующую, а отчёт — продукт, который клиент реально покупает. OWASP WSTG даёт веб-глубину: чек-лист кейсов с ID, чтобы «что мы тестировали?» имело буквальный, воспроизводимый ответ. Зрелый паттерн — прогнать чек-лист, чтобы дёшево забрать рутинное покрытие, затем потратить суждение на глубину там, где модель угроз говорит, что окупится. Так что увидев отчёт с одной находкой, тронувший лишь поверхности рядом с багом, твой первый вопрос: где остальное покрытие — что этот тест реально доказал про весь scope?
Практика
Начни сверху. Задачи идут от простого к сложному: вспомнить факт, применить к случаю, затем senior-уровень. Открой, попробуй, потом открой ответ.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.