Аудит безопасности сайта: инструменты и чек-лист

Аудит безопасности — не «прогнал сканер, получил отчёт». Сканер находит 20–40% проблем и при этом врёт в обе стороны: false positive захламляют список, false negative создают ложное чувство защиты. Реальный аудит — это методология: определить периметр, собрать разведку, прогнать инструменты по слоям, руками докопать то, что автоматика не видит, и оформить находки так, чтобы их починили.

Легальность прежде всего. Тестируйте только системы, на которые у вас есть письменное разрешение: свой сайт, контрактный стенд, bug bounty с явным scope. Сканирование чужого ресурса без согласия — уголовное правонарушение во многих юрисдикциях, независимо от «я же благое намерение».

Часть I. Методология и подготовка

1. Границы и разрешение

До первого запроса зафиксируйте письменно:

  • Scope: какие домены/поддомены/эндпоинты в деле. Что вне scope (сторонний платёжный шлюз, админка подрядчика).
  • Разрешение: кто владелец системы, когда действует, можно ли трогать прод или только стенд.
  • Правила engagement: можно ли нагружать (DoS-подобные тесты), можно ли трогать реальные данные пользователей, канал связи для критичных находок.
  • Бэкап и стенд: на проде деструктивные проверки (инъекции, загрузка файлов, брут) — запрещены; всё это — на копии.

Пропуск этого шага превращает аудит в источник инцидентов вместо их предотвращения.

2. Типы аудита: чем они отличаются

ТипЧто смотритДаётНе даёт
DAST (dynamic)работающее приложение «снаружи», через HTTPреальные цепочки, то что эксплуатируется сейчаспокрытие зависит от того, что просканировано; логику не видит
SAST (static)исходный кодвсе ветки кода, включая недоступные снаружиfalse positive; не видит рантайм-конфиг
Зависимости (SCA)версии библиотек + CVE-базыизвестные CVE в чужом кодене находит баги в вашем коде
Ручнойлогика, процессы, авторизациято, чего автоматика не умеетдорогой, зависит от скилла

Зрелый аудит комбинирует все четыре; «прогнали ZAP и выдохнули» — нет.

3. Разведка (recon) — собрать поверхность

Прежде чем сканировать, узнайте, что сканируете:

# Поддомены и DNS-периметр
dig +short example.com A AAAA MX TXT
# (для перебора поддоменов — amass / subfinder; только в своём scope!)

# Что стоит снаружи: версии, заголовки, fingerprint
curl -sI https://example.com
whatweb https://example.com          # CMS, сервер, заголовки

# Публичные страницы и карта сайта
curl -s https://example.com/robots.txt
curl -s https://example.com/sitemap.xml

# Для WordPress — отдельный плагин-аудит (см. Часть IV)

Задача этапа — понять стек (CMS, версия PHP по заголовкам, веб-сервер, плагины), потому что от стека зависит, какие проверки вообще актуальны.

Часть II. Инструменты по слоям

4. DAST — сканер работающего сайта

OWASP ZAP (Zed Attack Proxy) — основной рабочий инструмент: прокси-«man in the middle», пауки сайт, активное сканирование, пассивное обнаружение заголовков/кук, правила. Бесплатный, open source. Документация: zaproxy.org.

Типовой прогон (headless-скан против разрешённого стенда):

# Быстрое активное сканирование через baseline + full scan
zap-baseline.py -t https://staging.example.com -r report.html
zap-full-scan.py -t https://staging.example.com -r full.html \
                 -d zap.db -config spider.recursion=true

Как пользоваться осмысленно:

  • Прогоните аутентифицированный скан (с логином через ZAP session/макрос), иначе сканер видит только публичную часть и «не находит» половину.
  • Настройте scope strictly — иначе spider уползёт на внешние ссылки и (буквально) пойдёт атаковать чужой домен.
  • Все находки перепроверяйте руками. ZAP стабильно флажит «XSS» на ложках и «missing CSP» как «medium», тогда как реальный риск — другой.
  • Pacer/скорость: агрессивный full-scan на слабом стенде сам его уронит (непреднамеренный DoS) — снижайте интенсивность.

Nuclei (ProjectDiscovery) — шаблонный сканер: тысячи декларативных YAML-шаблонов под известные CVE/технологии/misconfig. Сканер «известных дыр», работает быстро на больших перечнях целей. Документация: nuclei github.

# Обновить шаблоны и прогнать по списку URL/хостов (своих!)
nuclei -update-templates
nuclei -l hosts.txt -severity critical,high -o nuclei-report.jsonl
# Отдельный класс — проверки по технологиям (WordPress, nginx, Apache)
nuclei -u https://staging.example.com -tags wordpress,misconfig -o wp-nuclei.txt

ZAP vs Nuclei не конкурируют: ZAP находит класс проблем по поведению, Nuclei — известные CVE и fingerprint-проблемы. Нужны оба, но оба — только подсказки до ручной сверки.

5. SAST — анализ своего кода

Здесь инструмент видит то, чего нет снаружи: SQLi в rarely-visited ручке, eval в админ-экране, неправильное экранирование в rarely-контексте (см. статью про XSS).

  • Semgrep — правила по коду с поддержкой языков; есть готовые security-наборы, свои правила легко писать. semgrep.dev.
  • Psalm / PHPStan (taint analysis) — для PHP: отслеживает потоки данных от $_GET/$_POST до опасных точек (execute, echo без экранирования).
  • RIPS-подобные анализаторы — классика PHP security SAST (проект ушёл из активной поддержки, идеи живы в Semgrep/Taint-правилах).
# Semgrep с секьюрити-правилами PHP
semgrep scan --config p/php --config p/security-audit src/
# Psalm с taint-режимом (taint analysis включается в psalm.xml)
./vendor/bin/psalm --taint-analysis

Главный минус SAST — false positive: он не знает, что вызывающий код фильтрует ввод. Находку трактуйте как «проверь это место», а не как «это дыра». Плюс — покрытие всех веток, включая те, до которых сканер снаружи не дошёл.

6. Зависимости (SCA) — известные CVE в чужом коде

Ваш код вы можете починить; чужой код — только обновить. Проверка зависимостей самый быстрый источник «бесплатных» находок.

# PHP: известные уязвимости в composer-пакетах
composer audit --format=plaintext

# JS: уязвимости в node_modules
npm audit --production

# Универсальный: скан по ОСВ-базе (OSV.dev, база CVE/GHSA)
osv-scanner scan --lockfile composer.lock
osv-scanner scan --lockfile package-lock.json

# WordPress отдельно — см. WPScan в Части IV

osv-scanner (github.com/google/osv-scanner) — от Google, работает по открытой базе уязвимостей OSV (агрегирует CVE, GitHub Advisory, и пр.), читает lock-файлы разных экосистем. Удобно в CI: падает пайплайн, если появилась известная дыра в зависимости.

Практический нюанс: «уязвимость в зависимости» ≠ «у вас эксплуатируемо». Проверьте, что уязвимый код-путь вообще используется (например, CVE в компоненте, который вы не вызываете, — это dependency bump, а не пожар). И наоборот, в ядре/CMS одна эксплуатируемая CVE может означать RCE — приоритет максимальный.

7. Внешний периметр: TLS, заголовки, DNS

7.1 SSL/TLS-конфиг

# Локальная проверка конфигурации TLS (шифры, протоколы, сертификаты)
testssl.sh https://example.com

Инструмент — testssl.sh на GitHub (репозиторий переехал из drwetter/* — старый путь теперь редиректит). Проверяет поддерживаемые протоколы (TLS 1.0/1.1 — плохо), слабые шифры (RC4, 3DES, export-grade), известные проблемы (Heartbleed, OpenSSL CVE, ROBOT), срок/цепочку сертификата, HSTS.

Быстрая онлайн-проверка — SSL Labs (Qualys): даёт итоговую оценку A–F и детальную картину. Публичный URL проверяется без установки.

7.2 Заголовки безопасности

CSP, X-Frame-Options/frame-ancestors, Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, Cookie-флаги. Детали каждого — в статье про XSS/CSRF.

  • Онлайн-экспресс: securityheaders.com — оценка A–F + рекомендации по заголовкам (учтите: при проверке curl/HEAD из скриптов сервис может отдавать 403 как bot-защита — это не ошибка сайта, открывайте в браузере).
  • Локально: curl -sI https://example.com и читать заголовки руками, сверяя с чек-листом.

7.3 DNS и прочее

Проверьте TXT (SPF/DMARC против спуфинга почты домена), отсутствие трансфера зоны (AXFR не для вашего NS), корректность CAA (кто может выпускать сертификат для домена), email/MX периметр.

Часть III. Что ловит только руками

8. Business logic — автоматика слепа

Сканер не знает, что значит ваш эндпоинт. Ручные проверки, которые стабильно находят дыры:

  • Целостность процессов. Можно ли пропустить шаг? («checkout» без проверки наличия товара; «2FA включена» до ввода подтверждающего кода; повторный перевод одним nonce.)
  • Манипуляции значениями. price=-100, quantity=1e9, coupon применённый дважды, discount=0.5 как строка.
  • Гонки (race conditions). Два параллельных запроса там, где ожидётся атомарность (купон, баланс, вывод денег). Проверяют параллельными повторами одного запроса.
  • Восстановление пароля. Одноразовость токена, срок, привязка к пользователю, можно ли «сбросить 2FA» только с доступом к почте (см. статью про аутентификацию).

9. Authorisation & IDOR — «правильные данные чужого пользователя»

В отличие от XSS, здесь код корректен, но не спрашивает «этот ли это объект?». Ручной тест:

  • Залогиньтесь пользователем A, запомните идентификаторы в URL/теле (/order/123, user_id=45).
  • Под пользователем B (или анонимом) подставьте эти идентификаторы. Если ответ отдаёт данные/меняет чужой ресурс — IDOR (OWASP A01 Broken Access Control).
  • Смените роль в сессии/параметре (role=user → role=admin) и проверьте, уважает ли сервер права на своих эндпоинтах (привилегия задаётся на сервере или приходит из клиента — см. mass-assignment в статье про API).

Плагин для перехвата и сравнения (в ZAP — Session Management/Authorization тест; отдельный инструмент — Burp Suite Auth Analyzer). Автоматика помогает, вывод — за человеком.

10. Конфигурация, которую видно только вживую

  • Дефолтные/тестовые страницы, /phpinfo(), debug-режим (WP_DEBUG с выводом на экран), раскрытие версий/stack traces.
  • Директории с листингом (/uploads/, /backups/), публичные .git/, .env, wp-config.php.bak.
  • Открытые бэкапы и дампы БД, логи, доступные по пути.
  • Неизменённые дефолтные креды админок.

Находки ищутся и curl-перебором путей, и в исходниках (SAST покажет .git в deploy-артефакте), и руками по чек-листу ниже.

Часть IV. Специфика WordPress

11. WPScan — плагин- и ядро-аудит

WPScan — специализированный сканер WordPress: версия ядра/тем/плагинов против своей базы CVE, enumeration пользователей (?author=, REST /wp/v2/users), поиск уязвимых плагинов/тем.

# Только в своём scope! -e = enumeration.
wpscan --url https://staging.example.com \
       --enumerate ap,at,tt,cb,dbe,u \
       --output wp-audit.json --format json

Ключевой смысл: плагины — главный риск WP-сайта. Ядро и топовые темы обновляются и проверяются; кустарный плагин из 2019 года с автором, сменившим e-mail — источник RCE. WPScan находит известные дыры в них; но и SAST/manual по коду самих плагинов обязателен, потому что «плагин у нас лежит на диске, а в базе WPScan о нём ничего нет» — типичный случай 0-day в вашем стеке.

12. Что дополнительно проверить руками в WP

  • Редакторы как RCE-точки: Theme Editor/Plugin Editor в админке, wp-admin/theme-editor.php, plugin-editor.php — любой админ уже умеет исполнять PHP на сервере по дизайну. Ограничьте права (или константой DISALLOW_FILE_EDIT).
  • REST/ enumeration: /wp-json/wp/v2/users отдаёт список логинов (топливо для брута); ?author=N раскрывает админские логины; wp-login без rate-limit.
  • xmlrpc.php: pingback-DRDoS, amplified brute (system.multicall). Проверить и отключить, если не нужен.
  • readme.html / license.txt / wp-content/debug.log: публичные артефакты, раскрывающие версию и внутренности.
  • Права на файлы: wp-config.php читается веб-процессом? uploads/ исполняемый (PHP-загрузка файлов = веб-шелл)? Проверить, что в uploads исполнение PHP запрещено на уровне конфига сервера.
  • Солевые ключи и AUTH_KEY — сгенерированы ли уникальными (дефолтные = уязвимость через rainbow/hash stealing cookies).

Часть V. Чек-лист аудита

13. Подготовка

  • Зафиксирован scope (in/out).
  • Есть бэкап и/или изолированный стенд для деструктивных проверок.
  • Настроен канал передачи критичных находок; определёно, что делать при обнаружении эксплуатируемой RCE.

14. Разведка и периметр

  • Собраны все поддомены/эндпоинты; проверен `robots.txt`/`sitemap.xml` (нет ли в robots секретных путей).
  • Определён стек (CMS/PHP/веб-сервер/плагины) — он задаёт набор проверок.
  • TLS: протоколы (нет 1.0/1.1), шифры (нет RC4/3DES/export), сертификат и цепочка, срок; `testssl.sh`/SSL Labs.
  • Заголовки: HSTS, CSP, `X-Content-Type-Options`, `Referrer-Policy`, `Permissions-Policy`, `frame-ancestors`; флаги кук (`HttpOnly/Secure/SameSite`).
  • DNS: SPF/DMARC, CAA, отсутствие трансфера зоны.

15. Автоматика

  • DAST: ZAP baseline + authenticated full scan (в строгом scope); находки перепроверены руками.
  • Nuclei по шаблонам (технологии + CVE).
  • SAST по своему коду: Semgrep/Psalm taint; false positive отфильтрованы.
  • Зависимости: `composer audit`, `npm audit`, osv-scanner; уязвимые версии обновлены либо подтверждена неэксплуатируемость пути.
  • WordPress: WPScan (ядро/темы/плагины/users) + отдельная ревизия плагинов.

16. Ручная проверка логики

  • IDOR: горизонтальная/вертикальная авторизация через подмену `id`/роли между A и B.
  • Business logic: пропуск шагов, отрицательные/гигантские значения, двойное применение купона, гонки.
  • Аутентификация: rate-limit входа, восстановление пароля (одноразовость/срок/привязка), смена пароля инвалидирует сессии, enumeration логинов закрыт.
  • Ввод/вывод: инъекции (SQLi/OS), XSS по контекстам, SSRF в фетчащих ручках, загрузка файлов (тип/размер/имя/исполняемость каталога).
  • Утечки/дефолты: `phpinfo`/debug, стектрейсы, `.git`/`.env`/бэкапы, открытые папки, дефолтные креды, `xmlrpc`.

17. Отчёт и повтор

  • Находки приоритизированы по эксплуатируемости, не по лейблу сканера.
  • У каждой: воспроизведение (шаг), риск, фикс; критичные — с временной линией починки.
  • План повторного аудита после починки + регресс-проверка закрываемых CVE.
  • Результаты и фиксы доведены до ответственного, а не сложены в PDF.

18. Как приоритизировать (порядок починки)

  1. Удалённое исполнение/загрузка файлов без аутентификации (RCE, веб-шелл в uploads).
  2. Поломки авторизации/аутентификации (IDOR к чужим данным, обход 2FA, дефолтные креды).
  3. Утечки данных (SQLi с выводом, открытые дампы/.env, логи с секретами).
  4. Клиентские атаки с доступом к сессии админа (stored XSS в админке).
  5. Конфигурация (заголовки, TLS, xmlrpc, debug-режим).
  6. Гигиена (версии ПО, метки, robots, мелочи без прямого риска).

Источники

👤 Зарегистрируйтесь, чтобы добавить материал в закладки.