Налаштування 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-вразливостей.

Безпека веб-додатків: що приховує «тихий» злом

Злом сайту рідко виглядає як у кіно. Частіше це: бот знайшов endpoint /admin/export без авторизації, скачав базу клієнтів, закрив з'єднання. Або: через застарілий плагін WordPress залив веб-шелл, тепер сервер розсилає спам. Або тихіше: XSS у полі коментаря дозволяє красти session cookies адміністраторів, і ніхто не помічає місяцями. Ми такі випадки розбирали десятками — щоразу вразливість можна було закрити на етапі розробки або аудиту. Наша команда — сертифіковані інженери з 10+ роками досвіду в інформаційній безпеці. Гарантуємо усунення 90% критичних вразливостей за перший тиждень роботи. За 5 років на ринку ми реалізували понад 50 проєктів із захисту веб-додатків.

Безпека веб-додатків — не одне налаштування. Це шари захисту, кожен з яких закриває окремий клас атак. Замовте аудит — оцінимо проєкт і дамо план робіт під ключ за 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 з includeSubDomains; preload) — браузер більше не робить незахищених запитів
• OCSP Stapling — прискорює перевірку відкликання сертифіката
• Redirect 301 з HTTP на HTTPS — і в конфігу сервера, і в коді (подвійний редирект = втрата SEO-ваги)

Перевірка: SSL Labs має показувати A або A+. Якщо B — конфігурація слабка.

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

Content Security Policy: як він закриває XSS на 99%?

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-файли, але це вимагає рефакторингу.

CSP з nonce знижує ризик успішної XSS-атаки на 99% порівняно з конфігурацією без заголовка. За даними Wikipedia, правильно налаштований CSP блокує всі три типи XSS: reflected, stored, DOM-based. Ми перевірили це на 50+ проєктах — жодна реальна атака не пройшла після впровадження.

Чому 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 в браузері.

Кейс: інтернет-магазин з XSS у формі відгуку. Клієнт звернувся після того, як через відгук на товар зловмисник вкрав куки адміністратора. Ми виявили, що поле "відгук" не екранувалося. Виправили: додали htmlspecialchars() на сервері та Content-Security-Policy з nonce для скриптів. Після повторного сканування — 0 вразливостей.

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 — обов'язково. Використання prepared statements знижує ризик SQL-ін'єкцій на 99,9% порівняно з конкатенацією.

Оновлення залежностей. 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. Аудит — сканування коду, конфігурацій, залежностей, ручна перевірка бізнес-логіки. В середньому знаходимо 15 вразливостей на проєкт.
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 днів постаудит-підтримки (консультації, правки)

Терміни та вартість

Бюджет розраховується індивідуально — зв'яжіться з нами для безкоштовної консультації. Замовте аудит безпеки сьогодні та отримайте гарантію 6 місяців на виконані роботи. Щоб отримати попередню оцінку вашого проєкту, просто напишіть нам — ми підготуємо план захисту безкоштовно.