Как мы тестируем: наша методология тестирования на проникновение

Ручной подход, потому что сканер видит лишь половину картины

Сканер превосходен в широте охвата: он определяет ПО, отмечает отсутствующие заголовки и сопоставляет известные сигнатуры CVE в тысячах запросов. Но он слаб в суждении. Он не поймёт, что `200 OK`, возвращающий счёт другого арендатора, — это критическая уязвимость нарушения контроля доступа, ведь синтаксически всё выглядит корректно. Злоупотребление бизнес-логикой, границы авторизации, цепочки уязвимостей низкой значимости и состояния гонки лежат ровно в той слепой зоне, о которой автомат не способен рассуждать.

Автоматизацию мы применяем осознанно — Burp Suite Professional, nuclei и точечные скрипты — как усилитель охвата и контроля регрессий, но никогда как сам тест. Именно специалист выдвигает гипотезы, изменяет состояние приложения и подтверждает реальное воздействие. В этом разница между «инструмент сообщил об этом» и «мы это доказали».

• Сканеры находят известные шаблоны; человек находит логику, которая шаблоном никогда не была.
• Авторизация, мультиарендность и злоупотребление процессами практически невидимы для сигнатурных инструментов.
• Автоматизация даёт охват и скорость; ручное тестирование даёт доказательство и контекст.

Фаза 1 — Подготовка: область, авторизация, правила проведения

Ни один пакет не отправляется до наличия подписанной авторизации. На этом этапе мы согласуем точную область (хосты, домены, приложения и API в области, а также явные исключения), окно тестирования, уровни учётных записей, под которыми тестируем, и контакты для эскалации. Правила проведения (Rules of Engagement) фиксируем письменно: что разрешено, что под запретом (например, без атак типа «отказ в обслуживании» и без разрушительных нагрузок на боевых данных), исходные IP для добавления в список разрешённых и аварийный канал на случай подозрения на реальную компрометацию или крайне хрупкую систему.

Цель мы формулируем на языке клиента — защита персональных данных, предотвращение захвата учётных записей, выполнение требования ISO 27001 или SOC 2 — чтобы усилия шли туда, где действительно лежит бизнес-риск, а не равномерно размазывались по шуму.

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

Фаза 2 — Разведка и картирование

Прежде чем зондировать поверхность атаки, мы строим её полную картину. За пассивной разведкой (DNS, журналы Certificate Transparency, публичный код и метаданные) следует активное картирование: перечисление хостов, портов и сервисов, обход приложения и каталогизация каждой конечной точки, параметра, потока аутентификации и роли. Это соответствует OWASP WSTG в разделах Information Gathering (WSTG-INFO) и Configuration Management (WSTG-CONF).

Результат этой фазы — внутренняя карта: что чему доверяет, где данные пересекают границу и какие конечные точки обрабатывают чувствительные объекты. Тест, который вы не додумались провести, — это уязвимость, которую вы никогда не найдёте, поэтому охват поверхности мы считаем полноценным показателем качества.

Фаза 3 — Моделирование угроз

Имея карту, мы рассуждаем как атакующий с целями. Мы выявляем значимые активы, границы доверия вокруг них и реалистичных субъектов угроз — неаутентифицированного пользователя из интернета, клиента с низкими привилегиями, злонамеренного инсайдера. Мы перечисляем сценарии злоупотреблений по каждому компоненту (в стиле STRIDE: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) и ранжируем их по вероятности и бизнес-воздействию.

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

Фаза 4 — Ручное тестирование и безопасная эксплуатация

Это ядро работы. Мы выполняем план по тест-кейсам OWASP WSTG и категориям OWASP Top 10, вручную проверяя каждую потенциальную проблему. Аутентификация и управление сессиями (WSTG-ATHN, WSTG-SESS), авторизация и IDOR/BOLA (WSTG-ATHZ), обработка ввода — injection, SQLi, XSS — (WSTG-INPV), бизнес-логика (WSTG-BUSL) и криптография (WSTG-CRYP) охватываются системно и соотносятся с контролями ASVS там, где полезен взгляд на зрелость.

Эксплуатация всегда безопасна и соразмерна. Уязвимость мы доказываем минимальным действием, необходимым для её демонстрации: чтением одной записи, к которой не должны иметь доступ, получением безобидного токена-доказательства, показом контролируемого `alert(document.domain)` для XSS. Мы никогда не выгружаем реальные данные клиентов, не запускаем разрушительные нагрузки и не снижаем доступность. Каждый шаг логируется с запросами и ответами и метками времени, чтобы находку можно было полностью воспроизвести.

• Системный охват категорий OWASP WSTG и OWASP Top 10.
• Доказательство воздействия наименее инвазивным действием — без кражи данных и разрушений.
• Полные доказательства запрос/ответ для побайтового воспроизведения.

Фаза 5 — После эксплуатации: измерение реального воздействия

Получение плацдарма — это ещё не находка; находка — это то, что этот плацдарм означает. Контролируемо и строго в рамках Rules of Engagement мы оцениваем, как далеко на самом деле дотягивается подтверждённая уязвимость: какие данные становятся читаемыми, можно ли повысить привилегии, складывается ли одна слабость в цепочку с другой и ведёт ли к самому ценному активу. Отражённый XSS — это одно; отражённый XSS, который крадёт сессию администратора и позволяет захватить арендатора целиком, — это уже другой разговор для бизнеса.

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

Фаза 6 — Оценка риска по CVSS v3.1

Каждая находка получает базовую оценку CVSS v3.1 и полную векторную строку, поэтому оценка прозрачна и независимо проверяема, а не является субъективным ярлыком. Мы оцениваем Attack Vector, Attack Complexity, Privileges Required, User Interaction, Scope и воздействие на Confidentiality/Integrity/Availability, а где уместно — добавляем метрики Temporal и Environmental, чтобы отразить реальный контекст клиента.

CVSS — это отправная точка, а не вся история. Числовую значимость мы соотносим с реальным бизнес-воздействием и эксплуатируемостью, поэтому технически «средняя» проблема, дающая захват учётной записи, повышается в описании и приоритизируется соответственно. Отчёт ранжирует проблемы так, чтобы усилия по устранению следовали за реальным риском.

Иллюстративный пример находки — IDOR в API счетов

Ниже — иллюстративный пример, показывающий, как мы документируем находку. Это не реальный клиент и не описывает никакую реальную систему.

Название: Insecure Direct Object Reference (IDOR), раскрывающий счета между арендаторами. Значимость: Высокая — CVSS v3.1 8.1 (вектор AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N). Категория: OWASP Top 10 A01:2021 Broken Access Control; WSTG-ATHZ-04 (Insecure Direct Object References).

Что мы нашли: конечная точка `GET /api/v2/invoices/{id}` возвращала объекты счетов по последовательному целочисленному идентификатору и авторизовала запрос лишь по наличию действующей сессии, никогда не проверяя, принадлежит ли счёт арендатору вызывающего. Аутентифицировавшись как пользователь с низкими привилегиями в Арендаторе A, мы изменили `{id}` с собственного `50432` на `50431` и получили счёт другой организации — имя клиента, платёжный адрес, позиции и сумму. Инкремент идентификатора позволял пройти всю таблицу.

Бизнес-воздействие: любой аутентифицированный клиент мог перечислить и прочитать все счета по всем арендаторам — массовое нарушение конфиденциальности персональных и коммерческих данных с явным риском по GDPR и договорными и репутационными последствиями.

Устранение: обеспечить авторизацию на уровне объекта на сервере для каждого запроса — проверять, что `tenant_id` запрошенного счёта совпадает с арендатором аутентифицированного субъекта перед возвратом, и возвращать `404` (а не `403`), чтобы не подтверждать существование ресурса. Заменить последовательные целочисленные идентификаторы неугадываемыми UUID как эшелонированную защиту и добавить автоматический тест контроля доступа в конвейер CI, чтобы регрессия не могла тихо вернуться.

• Значимость: Высокая — CVSS v3.1 8.1, вектор AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N.
• Первопричина: аутентификация есть, авторизация на уровне объекта отсутствует.
• Устранение: серверная проверка принадлежности арендатору + UUID + регрессионный тест контроля доступа в CI.

Фаза 7 — Отчётность, повторный тест и контроль качества

Отчёт — это продукт. Он открывается кратким резюме для руководства, за которым следуют технические находки — каждая с оценкой и вектором CVSS, шагами воспроизведения, доказательствами с метками времени, бизнес-воздействием и конкретной рекомендацией по устранению — не «пропатчите это», а конкретный контроль для внедрения. Находки ранжированы так, чтобы первое исправление снимало наибольший риск.

Качество обеспечивается до передачи: каждую находку проверяет второй специалист, независимо её воспроизводя, — так мы держим число ложных срабатываний около нуля, ведь мы не сообщаем о том, что не можем доказать. После устранения мы проводим бесплатный повторный тест, подтверждая, что каждое исправление действительно закрывает проблему и не вносит регрессию, и переиздаём отчёт с обновлённым статусом. Всё сопровождается NDA; доказательства и данные клиента шифруются в состоянии покоя, доступ к ним контролируется, они хранятся только согласованный срок и безопасно уничтожаются по графику.

• Проверка вторым специалистом с независимым воспроизведением — число ложных срабатываний около нуля.
• Конкретные, ранжированные рекомендации по устранению вместо общих советов.
• Бесплатный повторный тест после исправлений; NDA, шифрование и плановое уничтожение данных на всех этапах.

Частые вопросы