DAST Tooling

// SCENARIO — adding DAST to a defensive pipeline for an app you OWN or are explicitly
// authorised to test. Focus on configuration, detection, and remediation — not weaponisation.

// ─── 1) Quick start — OWASP ZAP baseline scan ──────────────────
// Docker is the easiest. Crawls + spiders + reports passive findings.
//
// docker run --rm -t -v $(pwd):/zap/wrk:rw ghcr.io/zaproxy/zaproxy:stable \\
//     zap-baseline.py \\
//     -t https://staging.example.com \\
//     -r zap-report.html \\
//     -J zap-report.json \\
//     -m 5                                  # max minutes for spider
//
// Baseline = passive only (no attack traffic). Safe to run nightly against staging.

// ─── 2) Full scan — active probing ─────────────────────────────
// docker run --rm -t -v $(pwd):/zap/wrk:rw ghcr.io/zaproxy/zaproxy:stable \\
//     zap-full-scan.py \\
//     -t https://staging.example.com \\
//     -r zap-full.html
//
// Full scan SENDS malicious payloads. Use only on staging / test environments with explicit
// authorisation. NEVER point at production without a written authorisation.

// ─── 3) Authenticated scan — sign in then crawl ────────────────
// Define a context with login script (or session cookie). Several options:
//   a) HTTP basic auth via -b
//   b) Form-based — record a Selenium login flow in ZAP's UI, export as a script
//   c) Bearer token in a custom header (Authorization)
//
// docker run --rm -t -v $(pwd):/zap/wrk:rw ghcr.io/zaproxy/zaproxy:stable \\
//     zap-full-scan.py \\
//     -t https://staging.example.com/app \\
//     -z '-config replacer.full_list(0).description=auth \\
//          -config replacer.full_list(0).enabled=true \\
//          -config replacer.full_list(0).matchtype=REQ_HEADER \\
//          -config replacer.full_list(0).matchstr=Authorization \\
//          -config replacer.full_list(0).replacement=Bearer eyJ...'

// ─── 4) GitHub Actions integration — staging gate ──────────────
// .github/workflows/dast.yml
name: dast-staging
on:
    schedule:
        - cron: '0 2 * * *'             # nightly 2am UTC
    workflow_dispatch:
jobs:
    zap:
        runs-on: ubuntu-latest
        steps:
            - uses: actions/checkout@v4
            - name: ZAP baseline
              uses: zaproxy/action-baseline@v0.12.0
              with:
                  target: https://staging.example.com
                  fail_action: true       # fail the workflow on high-severity findings
                  artifact_name: zap-baseline
            - if: failure()
              uses: actions/upload-artifact@v4
              with:
                  name: zap-report
                  path: report_html.html

// ─── 5) Nuclei — fast template-based scanner ───────────────────
// brew install nuclei  OR  docker pull projectdiscovery/nuclei
// nuclei -u https://staging.example.com -severity medium,high,critical \\
//     -tags cve,exposed-panels,misconfiguration \\
//     -rate-limit 50 \\
//     -o nuclei.out
//
// Nuclei runs 8000+ community-curated templates; great for known-CVE detection on perimeter.
// Pair with ZAP for application-layer logic flaws.

// ─── 6) Burp Suite Professional — interactive testing ──────────
// Use Burp for MANUAL testing, especially:
//   • Replaying requests with tweaks (Repeater)
//   • Fuzzing parameters (Intruder)
//   • Decoding / encoding payloads (Decoder)
//   • Modeling state-tracking auth flows
//   • Crawling SPAs that ZAP struggles with
//
// For CI: use Burp Suite Enterprise for scheduled scans, or stick with ZAP.

// ─── 7) Setting scope — never test outside the RoE ─────────────
// In ZAP / Burp, configure scope BEFORE scanning:
//   • Include only your domains/IPs in scope
//   • Exclude logout URLs, destructive endpoints, third-party widgets
//   • Exclude rate-limited endpoints unless you've negotiated a window
//
// For internal pentests, the Rules of Engagement (RoE) is the contract.
// Document:
//   • What URLs / IPs / accounts are in scope
//   • Time windows for active testing
//   • Out-of-scope (production data, customer accounts)
//   • Escalation contact when something breaks
//   • Data handling (no real customer data exfiltrated)

// ─── 8) Triage findings — sort the signal from the noise ───────
// DAST reports lots of low-confidence findings. Prioritise:
//   • CRITICAL — auth bypass, RCE, IDOR with sensitive data, stored XSS
//   • HIGH      — reflected XSS, SQLi, CSRF on state changes, secrets in headers
//   • MEDIUM    — info disclosure (server version, stack trace), missing security headers
//   • LOW        — debug pages, verbose error messages, default credentials on test boxes
//   • INFO       — known-good but suspicious patterns
//
// Reproduce each finding manually with curl before filing tickets — DAST has false positives.

// ─── 9) Filing tickets that engineers can act on ───────────────
// Each ticket should include:
//   • Endpoint (method + path + parameters)
//   • Reproducible curl command (the smallest example)
//   • What the scanner detected vs what was expected
//   • Suggested fix mapped to the codebase (e.g. 'parameterise this query in src/db/users.py:42')
//   • Severity + impact in plain English
//   • CWE / OWASP Top 10 mapping for context

// ─── 10) ZAP API — drive scans from scripts ───────────────────
import requests, time

ZAP = 'http://localhost:8080'
TARGET = 'https://staging.example.com'
API_KEY = '...'   # set via -config api.key in ZAP

requests.get(f'{ZAP}/JSON/spider/action/scan/', params={'apikey': API_KEY, 'url': TARGET})
while True:
    r = requests.get(f'{ZAP}/JSON/spider/view/status/', params={'apikey': API_KEY}).json()
    if int(r['status']) >= 100: break
    time.sleep(2)

requests.get(f'{ZAP}/JSON/ascan/action/scan/', params={'apikey': API_KEY, 'url': TARGET})
# Poll active scan status, then export report.

// ─── 11) DAST vs SAST vs IAST vs SCA ──────────────────────────
// SAST — static; scans source code (Semgrep, CodeQL)
// DAST — dynamic; scans running app (ZAP, Burp, Nuclei)
// IAST — runtime instrumentation, hybrid (Contrast, Seeker)
// SCA  — software composition (deps + CVEs) (Snyk, Trivy, Dependabot)
//
// Defence in depth: ALL FOUR run in CI. Each catches different bug classes.

// ─── 12) Production scanning — only with authorisation ────────
// • Most policies disallow production active scanning
// • Schedule maintenance windows; alert the SOC ahead of time
// • Use READ-ONLY findings (baseline / passive) on prod if you must
// • Better: scan staging that mirrors prod schema + data shapes (synthetic)

// ─── 13) Re-test after fixes ─────────────────────────────────
// Mark findings as 'fixed' in your tracking system + re-scan to confirm.
// Track time-to-fix as a metric — leadership cares.

// ─── 14) Combine with security tests in CI ────────────────────
// Pyramid:
//   • Unit tests for security-critical functions (auth, authz, parsing)
//   • Integration tests with malicious inputs ('attack-mode' test suite)
//   • DAST nightly against staging
//   • Penetration test quarterly
//   • Bug bounty if mature

// ─── 15) Common bugs / mistakes ──────────────────────────────
// • Pointing DAST at production without authorisation
// • Aggressive scan rates → DDOS your own service; rate-limit and coordinate
// • False positives ignored without triage → real bugs hidden in the noise
// • Scanning behind a WAF that strips payloads → DAST reports clean, real bug still present; test BOTH paths
// • Tokens in URLs leaked into logs/reports → strip auth before publishing
// • Skipping authentication during scans → 90% of app surface invisible
// • Treating DAST as the only tool — DAST + SAST + SCA + manual review together

// Black-box scanners poke the running app: ZAP, Burp, Acunetix.
// Schedule against staging; treat findings as bugs with a security label.