Настройка DAST для сайта: динамический анализ безопасности

Проблема: уязвимости, которые не видит SAST

Вы используете статический анализ кода, но production всё равно взламывают через неправильную конфигурацию Nginx или IDOR в API, который не покрыт тестами. SAST анализирует код, а работает приложение в окружении — с сервером, middleware, сторонними сервисами. Именно здесь возникают runtime-уязвимости. DAST (Dynamic Application Security Testing) решает эту проблему: он атакует приложение как внешний злоумышленник и находит то, что скрыто от статики.

Мы настраиваем DAST для сайтов и API уже 10+ лет. За это время провели более 50 проектов по безопасности, от интернет-магазинов до финтех-платформ. Один из кейсов: клиент потерял 2 млн ₽ из-за SQL-инъекции, которую не видел SAST. После внедрения ZAP в CI/CD такие уязвимости перестали попадать в production. В среднем экономия на ручном аудите достигает 70% — автоматизация окупается за пару месяцев. По данным OWASP Top 10, около 40% критических уязвимостей относятся к runtime-категории, а средняя стоимость утечки данных для中小 бизнеса — 3 млн ₽.

Почему DAST не заменить SAST?

DAST проверяет работающее приложение в реальном окружении. Он видит:

• Неправильную конфигурацию сервера (открытые CORS, слабые заголовки)
• Runtime-уязвимости (RCE, SSRF, IDOR)
• Проблемы с аутентификацией (невалидные сессии, слабые токены)

SAST анализирует код, но не знает, как он исполняется. DAST же действует с точки зрения хакера. Например, X-Frame-Options настраивается на сервере, и SAST его не проверит. DAST отправит запрос и увидит, что заголовок отсутствует. Без DAST вы рискуете пропустить до 95% runtime-уязвимостей, которые составляют 40% всех критических проблем.

Как интегрировать DAST в CI/CD?

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

1. Выбор инструмента: для веб-сайтов — OWASP ZAP (open source, гибкий), для API — ZAP API scan или Nuclei.
2. Настройка правил: определяем, какие уязвимости критичны (SQLi, XSS), а какие — предупреждения.
3. Интеграция с CI/CD: запуск при каждом пуше или по расписанию, генерация отчёта, фейл пайплайна при критических находках.
4. Кастомизация: добавляем authentication, настраиваем scope, исключаем чувствительные эндпоинты.

Пример OWASP ZAP в GitHub Actions

# .github/workflows/dast.yml
name: DAST

on:
  push:
    branches: [main]
  schedule:
    - cron: '0 2 * * 1'

jobs:
  zap-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Start application
        run: |
          docker compose -f docker-compose.test.yml up -d
          sleep 30

      - name: Run ZAP Baseline Scan
        uses: zaproxy/[email protected]
        with:
          target: http://localhost:3000
          rules_file_name: .zap/rules.tsv
          cmd_options: '-a'

      - name: Upload ZAP report
        uses: actions/upload-artifact@v4
        if: always()
        with:
          name: zap-report
          path: report_html.html

      - name: Stop application
        if: always()
        run: docker compose -f docker-compose.test.yml down

# .zap/rules.tsv
# rule_id  action  reason
10017      WARN    # X-Frame-Options header
10038      WARN    # Content Security Policy
40012      FAIL    # Cross Site Scripting
40018      FAIL    # SQL Injection
90011      IGNORE  # Charset mismatch

Сравнение инструментов DAST

ZAP лучше для автоматизации в CI/CD: быстрый baseline scan (5-10 мин) и детальный full scan. Nuclei эффективен для проверки конкретных CVE — вы запускаете его за 5 минут и получаете список известных уязвимостей. Burp Suite используется для ручного пентеста, когда нужно глубоко протестировать бизнес-логику.

Таблица этапов настройки DAST

Что входит в настройку DAST

В рамках услуги мы:

• Анализируем архитектуру приложения и выбираем инструменты.
• Настраиваем OWASP ZAP (или Nuclei) в вашем CI/CD (GitHub Actions, GitLab CI, Jenkins).
• Пишем кастомные правила для фильтрации ложных срабатываний.
• Настраиваем автоматический регресс: если в новой версии появилась критическая уязвимость — пайплайн падает.
• Подключаем сканирование по расписанию (еженедельно).
• Обучаем команду работе с отчётами и интерпретации результатов.
• Предоставляем документацию: конфигурации, правила, инструкцию по добавлению нового проекта.
• Сопровождаем 2 недели после внедрения: корректируем правила, добавляем исключения.

Типичные ошибки при внедрении DAST

1. Сканирование production-окружения. Активное сканирование может сломать данные. Всегда используйте staging.
2. Игнорирование аутентификации. DAST должен ходить как авторизованный пользователь, иначе он не увидит защищённые эндпоинты.
3. Отсутствие фильтрации ложных срабатываний. Без кастомных правил ZAP выдаёт сотни предупреждений, которые никто не смотрит.
4. Запуск только ручного сканирования. Автоматизация в CI/CD — единственный способ не пропускать уязвимости.

Сроки и стоимость

Сроки зависят от сложности:

• Базовая настройка ZAP в CI/CD: 1-2 дня.
• • Nuclei и Burp Suite: 3-5 дней.
• Кастомизация правил и автотесты: до 7 дней.

Стоимость рассчитывается индивидуально. Вы получаете стабильный DAST-пайплайн, который защищает от критических уязвимостей. Получите консультацию — мы обсудим ваш проект и подберём оптимальное решение. Мы гарантируем, что настройка не сломает staging, и предоставляем поддержку после внедрения.

# rule_id  action  reason
90001      IGNORE  # Application error disclosure
90011      IGNORE  # Charset mismatch
10017      WARN    # X-Frame-Options header
10038      WARN    # Content Security Policy
40012      FAIL    # Cross Site Scripting
40018      FAIL    # SQL Injection

Свяжитесь с нами, чтобы начать настройку DAST уже сегодня. Закажите консультацию — мы поможем защитить ваш проект от runtime-уязвимостей.

Безопасность веб-приложений: HTTPS, CSP, XSS, CSRF, WAF, защита от DDoS

Взлом сайта редко выглядит как в кино. Чаще это: бот нашёл endpoint /admin/export без авторизации, скачал базу клиентов, закрыл соединение. Или: через устаревший плагин WordPress залил веб-шелл, теперь сервер рассылает спам. Или тише: XSS в поле комментария позволяет красть session cookies администраторов, и никто не замечает месяцами. Мы такие случаи разбирали десятками — каждый раз уязвимость можно было закрыть на этапе разработки или аудита.

Безопасность веб-приложений — не одна настройка. Это слои защиты, каждый из которых закрывает отдельный класс атак. Закажите аудит — оценим проект и дадим план работ под ключ за 2–4 недели.

HTTPS и правильная конфигурация TLS

HTTPS — минимальный обязательный уровень. Но «есть SSL-сертификат» и «правильно настроен TLS» — разные вещи.

В конфигурации Nginx/Apache проверяем:

• Протоколы: только TLS 1.2 и TLS 1.3, SSLv3 и TLS 1.0/1.1 — отключены
• Cipher suites: предпочитать ECDHE (Forward Secrecy), убрать NULL, RC4, DES, 3DES
• HSTS (Strict-Transport-Security: max-age=31536000; includeSubDomains; preload) — браузер больше не делает незащищённых запросов
• OCSP Stapling — ускоряет проверку отзыва сертификата
• Redirect 301 с HTTP на HTTPS — и в конфиге сервера, и в коде (двойной редирект = потеря SEO-веса)

Проверка: SSL Labs (ssllabs.com/ssltest) должен показывать A или A+. Если B — конфигурация слабая.

Let's Encrypt + Certbot для продакшена — стандарт. Автоматическое обновление через certbot renew в cron. Wildcard-сертификат для поддоменов через DNS-01 challenge.

Content Security Policy: самая мощная и самая сложная защита

CSP — HTTP-заголовок, который говорит браузеру, откуда разрешено загружать ресурсы. Правильно настроенный CSP полностью блокирует большинство XSS-атак, даже если уязвимость есть в коде.

Проблема: сломать сайт неправильным CSP проще простого. default-src 'none' — и перестают работать шрифты, картинки, JS. Поэтому начинаем с Content-Security-Policy-Report-Only — CSP логирует нарушения, но ничего не блокирует. Смотрим репорты 2–4 недели, дорабатываем политику, потом переключаем на боевой режим.

Пример реальной политики для сайта с Google Analytics, Google Fonts и Stripe:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://www.googletagmanager.com https://js.stripe.com 'nonce-{random}';
  style-src 'self' https://fonts.googleapis.com 'unsafe-inline';
  font-src 'self' https://fonts.gstatic.com;
  frame-src https://js.stripe.com;
  img-src 'self' data: https://www.google-analytics.com;
  connect-src 'self' https://api.stripe.com https://www.google-analytics.com;
  report-uri /csp-report;

nonce — случайная строка, генерируется на сервере для каждого запроса. Inline-скрипты с правильным nonce разрешены, без nonce — заблокированы. Это ломает XSS через <script>alert(1)</script> полностью.

'unsafe-inline' в style-src — компромисс для inline-стилей. Лучше убрать, перенеся все стили в CSS-файлы, но это требует рефакторинга.

Почему XSS остаётся самой частой уязвимостью?

XSS (Cross-Site Scripting) — инъекция JS-кода через пользовательский ввод. По статистике OWASP, XSS входит в топ-3 уязвимостей веб-приложений. Три типа:

Защита: никогда не вставлять пользовательский ввод в HTML без эскейпинга. В PHP — htmlspecialchars() с ENT_QUOTES. В Blade-шаблонах Laravel — {{ $var }} безопасен, {!! $var !!} — опасен. В React — {variable} безопасен, dangerouslySetInnerHTML — опасен. Для Rich Text — htmlpurifier на PHP или DOMPurify в браузере.

CSRF: защита форм и API

CSRF (Cross-Site Request Forgery) — злоумышленник заставляет браузер жертвы отправить запрос от её имени. Пример: пользователь авторизован в банке, открывает вредоносную страницу, она делает fetch('https://bank.ru/transfer?to=evil&amount=50000') — если банк не защищён, деньги уходят.

CSRF-токены — стандартная защита для форм: сервер генерирует случайный токен, хранит в сессии, вставляет в форму как hidden field. При POST-запросе токен сверяется. Злоумышленник не знает токен. Laravel делает это автоматически через @csrf.

SameSite cookies — современная защита: SameSite=Strict или SameSite=Lax запрещает браузеру отправлять cookie в cross-site запросах. Работает во всех современных браузерах.

API без сессий (JWT, Bearer tokens) — CSRF неактуален, если токен не хранится в cookie (а в Authorization header или localStorage). Но localStorage уязвим к XSS — поэтому для чувствительных данных предпочтительны HttpOnly cookies с SameSite.

WAF и защита от DDoS

WAF (Web Application Firewall) — фильтрует HTTP-трафик на предмет атак: SQL injection, XSS, path traversal, известные exploit patterns. Варианты:

• Cloudflare WAF — облачный, правила OWASP Top 10 из коробки, кастомные правила через выражения. Managed Rules автоматически блокируют новые угрозы.
• ModSecurity (Nginx/Apache) — self-hosted, OWASP Core Rule Set (CRS). Гибко, но требует настройки и мониторинга ложных срабатываний.
• AWS WAF — для инфраструктуры на AWS, интегрируется с CloudFront и ALB.

DDoS-защита. Cloudflare на уровне L3/L4/L7 — де-факто стандарт для большинства сайтов. Автоматическое смягчение volumetric атак, Under Attack Mode при активной атаке. Для критичной инфраструктуры — Cloudflare Magic Transit или специализированные решения (Qrator, StormWall для российского рынка).

Rate Limiting на уровне приложения — дополнительный слой. Laravel ThrottleRequests middleware: 60 запросов в минуту на IP для общих endpoint, 5 — для /login и /password/reset. Redis как хранилище счётчиков — обязательно для горизонтально масштабируемых систем (иначе лимиты не синхронизируются между серверами).

Другие обязательные меры

Заголовки безопасности. Помимо CSP: X-Frame-Options: DENY (защита от clickjacking), X-Content-Type-Options: nosniff (MIME sniffing), Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy (ограничение доступа к API браузера: камера, микрофон, геолокация).

SQL injection. Prepared statements везде. Никаких конкатенаций пользовательского ввода в SQL-строки. ORM (Eloquent, Doctrine) защищает по умолчанию. $wpdb->prepare() в WordPress — обязательно.

Обновления зависимостей. composer audit и npm audit — в CI/CD пайплайн. Dependabot или Renovate для автоматических PR с обновлениями. Критичные CVE — патчить в течение 24 часов.

Секреты и конфигурация. .env — никогда в Git. Секреты в production — через переменные окружения CI/CD (GitHub Secrets, GitLab CI Variables) или HashiCorp Vault. Проверка на утечки: git-secrets, truffleHog в pre-commit hooks.

Как мы работаем

1. Аудит — сканирование кода, конфигураций, зависимостей, ручная проверка бизнес-логики.
2. Проектирование — план устранения уязвимостей, подбор стека (CSP, WAF, rate limiting).
3. Реализация — настройка TLS, CSP, заголовков, внедрение Rate Limiting, WAF.
4. Тестирование — повторный пентест, нагрузочное тестирование, проверка ложных срабатываний.
5. Деплой и мониторинг — включение боевого CSP, настройка алертов, обучение команды.

Что входит в работу

• Отчёт с найденными уязвимостями и рекомендациями (PDF + code snippets)
• Готовая конфигурация TLS (Nginx/Apache)
• Политика CSP с режимом Report-Only и боевой версией
• Настройка WAF и Rate Limiting
• План обновлений зависимостей
• Доступы к инструментам мониторинга (Sentry, Datadog)
• 30 дней постаудит-поддержки (консультации, правки)

Сроки и стоимость

Бюджет рассчитывается индивидуально — напишите нам, чтобы оценить проект.