OWASP Top 10 для начинающего пентестера: карта основных классов веб-рисков без заучивания payload

OWASP Top 10 — это не список уязвимостей для заучивания, а классификация рисков, которая помогает пентестеру структурировать проверку веб-приложения. Вместо того чтобы запоминать сотни конкретных payload, достаточно понимать, какой класс проблем стоит за каждой категорией, какие индикаторы искать и как интерпретировать результаты.

Актуальная выпущенная версия — OWASP Top 10 2025. Предыдущая редакция 2021 года остаётся широко используемым ориентиром, и именно её категории формируют базу для большинства методик тестирования. Ниже разбор построен на структуре 2021, поскольку она покрывает те же фундаментальные классы рисков.

Как читать список пентестеру​


Каждая категория OWASP Top 10 описывает не одну уязвимость, а целое семейство проблем с общей корневой причиной. Например, A03 Injection включает SQL-инъекции, XSS, command injection, LDAP-инъекции и другие варианты — всё, где недоверенные данные попадают в интерпретатор. Пентестеру важно удерживать именно этот уровень абстракции: не «какой payload отправить», а «где приложение передаёт пользовательский ввод в контекст, который его интерпретирует».

Практический подход к каждой категории:

  1. Понять, какой механизм защиты должен быть на месте.
  2. Определить, где этот механизм может отсутствовать или работать некорректно.
  3. Проверить наличие индикаторов в учебной среде.
  4. Оценить влияние и сформулировать рекомендацию.

A01: Broken Access Control​


Самая распространённая категория. Суть: приложение не проверяет, имеет ли текущий пользователь право на запрошенное действие или ресурс.

Что искать при тестировании:

  • Прямые ссылки на объекты (IDOR): замена идентификатора в URL или теле запроса приводит к доступу к чужим данным.
  • Повышение привилегий: обычный пользователь получает доступ к административным endpoint.
  • Отсутствие проверки на стороне сервера: интерфейс скрывает кнопку, но API-запрос проходит.
  • CORS-мисконфигурация, позволяющая чужому домену читать ответы.

Индикаторы: HTTP 200 вместо 403 при обращении к чужому ресурсу, изменение роли без повторной аутентификации, доступ к /admin без редиректа.

Направление remediation: deny by default, проверка прав на сервере для каждого запроса, использование непредсказуемых идентификаторов ресурсов.

A02: Cryptographic Failures​


Ранее категория называлась Sensitive Data Exposure. Фокус сместился на первопричину — некорректную криптографию.

Что искать:

  • Передача чувствительных данных по HTTP без TLS.
  • Использование устаревших алгоритмов (MD5, SHA-1 для хранения паролей, DES, RC4).
  • Хранение паролей в открытом виде или с обратимым шифрованием вместо хеширования.
  • Отсутствие заголовков безопасности (HSTS, Cache-Control для чувствительных страниц).
  • Жёстко заданные ключи в исходном коде или конфигурации.

Индикаторы: Set-Cookie без флага Secure, ответы с персональными данными без Cache-Control: no-store, TLS-сертификат с истёкшим сроком или самоподписанный на продакшене.

Понимание HTTP-заголовков и механизмов сессий здесь критично — см. HTTP для начинающего пентестера: методы, коды ответа, заголовки, cookies и сессии.

A03: Injection​


Любая ситуация, когда недоверенные данные попадают в интерпретатор без надлежащей нейтрализации.

Подтипы, которые покрывает категория:

ПодтипКуда попадает вводТипичный контекст
SQL-инъекцияСУБДПараметры запросов, формы поиска, URL
XSSБраузер пользователяОтражение ввода в HTML, атрибутах, JS
Command injectionОС-оболочкаОбработка файлов, ping-утилиты, конвертация
LDAP-инъекцияКаталогФильтры поиска пользователей
Template injectionШаблонизаторРендеринг пользовательских шаблонов

Что искать: поля ввода, параметры URL, заголовки (User-Agent, Referer, X-Forwarded-For), которые отражаются в ответе или передаются в серверную логику. Ключевой вопрос: «Интерпретируется ли этот ввод как код или как данные?»

Направление remediation: параметризованные запросы, контекстное экранирование при выводе, allowlist-валидация, использование ORM и шаблонизаторов с автоэкранированием.

A04: Insecure Design​


Категория, добавленная в 2021 году. Отличается от остальных: речь не о реализации, а об архитектурных решениях, которые создают уязвимость ещё до написания кода.

Примеры проблем:

  • Отсутствие rate limiting на критичных операциях (сброс пароля, подбор OTP).
  • Бизнес-логика, позволяющая обойти оплату или лимиты.
  • Отсутствие многофакторной аутентификации для привилегированных операций.

Что искать при тестировании: сценарии, где последовательность легитимных действий приводит к нелегитимному результату. Это не баг в коде — это баг в проектировании.

A05: Security Misconfiguration​


Широкая категория, покрывающая всё, что связано с настройкой инфраструктуры и фреймворков.

Что искать:

  • Дефолтные учётные записи и пароли.
  • Подробные сообщения об ошибках в продакшене (stack trace, версии библиотек).
  • Ненужные HTTP-методы (TRACE, PUT, DELETE), если они не используются.
  • Открытые директории с листингом.
  • Устаревшие или ненужные модули сервера.
  • Отсутствие заголовков безопасности (X-Content-Type-Options, X-Frame-Options, CSP).

Индикаторы: страница с версией фреймворка в footer, ответ 200 на TRACE /, XML-листинг директории.

A06: Vulnerable and Outdated Components​


Использование библиотек, фреймворков и модулей с известными уязвимостями.

Что искать:

  • Версии библиотек в ответах сервера, заголовках, путях (/js/jquery-1.8.3.min.js).
  • Известные CVE для обнаруженных версий.
  • Компоненты, которые больше не поддерживаются.

Подход: идентификация стека технологий → сопоставление версий с базами уязвимостей (NVD, GitHub Advisory Database). Это не эксплуатация, а инвентаризация рисков.

A07: Identification and Authentication Failures​


Проблемы в механизмах аутентификации и управления сессиями.

Что искать:

  • Разрешён brute force (нет блокировки, нет rate limit, нет CAPTCHA).
  • Сессия не инвалидируется после выхода или смены пароля.
  • Cookie сессии без флагов HttpOnly и Secure.
  • Предсказуемые или слабые токены сессии.
  • Отсутствие многофакторной аутентификации для критичных операций.

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

A08: Software and Data Integrity Failures​


Категория, добавленная в 2021 году. Покрывает ситуации, когда код или данные принимаются из недоверенных источников без проверки целостности.

Что искать:

  • Загрузка обновлений или плагинов без проверки подписи.
  • Десериализация недоверенных данных (Java ObjectInputStream, PHP unserialize, Python pickle).
  • CDN-скрипты без атрибута integrity (Subresource Integrity).
  • CI/CD-пайплайны без контроля доступа к артефактам.

A09: Security Logging and Monitoring Failures​


Отсутствие или неадекватность логирования и мониторинга. Эта категория не создаёт уязвимость напрямую, но делает все остальные категории критичнее, потому что атака остаётся незамеченной.

Что искать:

  • Аудит-лог не фиксирует попытки аутентификации, изменение прав, доступ к чувствительным данным.
  • Логи хранятся только локально и не защищены от модификации.
  • Отсутствие алертов на аномальную активность.

Для пентестера: если в отчёте нет рекомендаций по логированию — отчёт неполный. Обнаружение уязвимости без оценки того, могла ли она быть замечена, снижает ценность находки.

A10: Server-Side Request Forgery (SSRF)​


Приложение выполняет HTTP-запрос к адресу, который контролирует или частично контролирует пользователь.

Что искать:

  • Поля ввода URL (webhook, импорт данных, preview ссылки).
  • Запросы к внутренним адресам (127.0.0.1, 169.254.169.254, 10.x.x.x).
  • Обход фильтров через альтернативные представления IP (десятичное, шестнадцатеричное, IPv6).
  • Протоколы помимо HTTP: file://, gopher://, dict://.

Индикаторы: разница во времени ответа при обращении к внутреннему vs внешнему адресу, изменение содержимого ответа в зависимости от указанного URL.

Как применять это в учебном пентесте​


OWASP Top 10 — это чек-лист для структурирования проверки, а не инструкция по эксплуатации. В авторизованном пентесте или учебной лаборатории последовательность обычно такая:

  1. Разведка. Определить стек технологий, endpoint, параметры. Здесь помогает понимание DNS и HTTP — см. HTTP для начинающего пентестера: методы, коды ответа, заголовки, cookies и сессии, DNS для начинающего пентестера: записи, резолвинг и безопасная диагностика в учебной сети.
  2. Маппинг по категориям. Для каждого обнаруженного компонента определить, какие категории OWASP Top 10 релевантны.
  3. Проверка индикаторов. Не эксплуатация, а фиксация признаков: неожиданные коды ответа, отражение ввода, отсутствие заголовков.
  4. Оценка влияния. Если индикатор подтверждён — определить, какие данные или функции затронуты.
  5. Формулировка рекомендации. Конкретное действие для разработчика: не «исправить XSS», а «добавить контекстное экранирование в шаблоне X при выводе параметра Y».

Где тренироваться безопасно​


Заучивать payload без понимания контекста — тупиковый путь. Вместо этого стоит работать в специально подготовленных средах:

  • PortSwigger Web Security Academy — бесплатные интерактивные лаборатории, покрывающие все категории OWASP Top 10. Каждая тема объяснена текстом, затем закрепляется практическим заданием в изолированной среде. Доступно с Burp Suite Community Edition.
  • OWASP WebGoat / Juice Shop — намеренно уязвимые приложения для локального развёртывания.
  • DVWA (Damn Vulnerable Web Application) — классическая учебная платформа с переключением уровня сложности.

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

Типичные ошибки начинающего​


ОшибкаПочему это проблемаЧто делать вместо этого
Копировать payload из шпаргалки без пониманияНе работает, если контекст отличаетсяРазобраться, какой интерпретатор и какой контекст
Искать только SQL-инъекцию и XSSПропускаются access control, SSRF, misconfigurationПроходить по всем 10 категориям последовательно
Не документировать отрицательные результатыЗаказчик не видит объём работыФиксировать: «проверено, не обнаружено, метод проверки»
Путать finding и vulnerability«Отсутствует заголовок X-Frame-Options» — не всегда уязвимостьОценивать реальное влияние в контексте приложения
Игнорировать бизнес-логикуA04 Insecure Design не ловится сканеромСтроить сценарии злоупотребления легитимными функциями

Итоговый чек-лист для самопроверки​


  • [ ] Знаю, какая версия OWASP Top 10 актуальна и чем она отличается от предыдущей.
  • [ ] Могу для каждой категории назвать корневую причину и минимум два индикатора.
  • [ ] Понимаю разницу между A03 Injection и A04 Insecure Design.
  • [ ] Умею проверить наличие заголовков безопасности и интерпретировать их отсутствие.
  • [ ] Работал хотя бы в одной учебной лаборатории по каждой категории.
  • [ ] Могу сформулировать рекомендацию для разработчика конкретным языком.
  • [ ] Не тестирую реальные приложения без письменного согласования scope.

Источники​


 
Назад
Верх Низ