DAST (sqlmap)

// SCENARIO — authorised testing of YOUR app's API for SQL injection. Defensive engineering and tooling.

// ─── 1) sqlmap — the canonical SQLi scanner ────────────────────
//
// Install:
// pip install sqlmap   OR   brew install sqlmap
//
// Basic scan against a URL you OWN
sqlmap -u 'https://staging.example.com/api/products?id=1' --batch

// Authenticated
sqlmap -u 'https://staging.example.com/api/orders/42' \\
    --cookie 'sid=staging-test-user-123' \\
    --batch --random-agent

// Provide a request file captured from Burp / browser (the safest way to model your real request)
sqlmap -r request.txt --batch --risk=3 --level=5 --threads=4

// What sqlmap does:
//   • Identifies injection points (URL params, headers, cookies, POST body)
//   • Detects injection class (boolean, error, time-based, union, stacked)
//   • Detects backend DBMS (MySQL, Postgres, Oracle, MSSQL, SQLite)
//   • Extracts data when allowed (--dbs, --tables, --columns, --dump)
//   • Only use --dump on TEST DATA

// 2) OWASP ZAP — broader scanner including SQLi rules
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.html

// SQLi-specific rules: 'SQL Injection' (40018), 'SQL Injection - Boolean Based' (40019)
// Configure scope, login, and exclusions in zap-config.yaml before running.

// 3) Nuclei — fast template-based scanner
nuclei -u https://staging.example.com -tags sqli -severity medium,high,critical
// Templates cover common injection patterns + CVE-specific SQLi bugs.

// 4) CI integration — guardrails on PRs / nightly
// .github/workflows/dast-sqli.yml
name: dast-sqli
on:
    schedule: [{ cron: '0 2 * * *' }]
    workflow_dispatch:
jobs:
    scan:
        runs-on: ubuntu-latest
        steps:
            - uses: actions/checkout@v4
            - name: Run ZAP
              uses: zaproxy/action-baseline@v0.12.0
              with:
                  target: https://staging.example.com
                  fail_action: true
            - name: Run Nuclei
              uses: projectdiscovery/nuclei-action@main
              with:
                  target: https://staging.example.com
                  templates: 'cves,vulnerabilities,exposures,misconfiguration'
                  severity: 'medium,high,critical'
            - if: failure()
              uses: actions/upload-artifact@v4
              with: { name: scan-reports, path: '*.html' }

// 5) sqlmap in CI — careful! Active probing on a target
// • Only against a dedicated TEST environment
// • With test users that have no real data
// • Within scheduled maintenance windows
# .github/workflows/sqlmap.yml
jobs:
    sqlmap:
        runs-on: ubuntu-latest
        steps:
            - run: pip install sqlmap
            - run: |
                  sqlmap -u 'https://staging.example.com/api/products?id=1' \\
                      --batch --risk=2 --level=3 --threads=2 \\
                      --output-dir=./sqlmap-output \\
                      --time-sec=2
            - if: failure()
              uses: actions/upload-artifact@v4
              with: { name: sqlmap-out, path: ./sqlmap-output }

// 6) Triaging findings
// • CRITICAL: any confirmed injection with data extraction
// • HIGH:      blind / time-based detection without extraction
// • MEDIUM:    error-disclosure that hints at SQLi but no payload landed
// • INFO:      DB version disclosure, error pages
//
// For each CRITICAL/HIGH:
//   1. Reproduce manually with the exact payload
//   2. Locate the offending code via stack trace / endpoint owner
//   3. Replace string concat with parameterised query
//   4. Add a regression test (curl the same payload, expect safe response)
//   5. Re-scan after deploy to confirm fix

// 7) Pair DAST with SAST + manual review
// • SAST (Semgrep, CodeQL) catches concat-style SQLi at code level — see sqli/static
// • DAST catches runtime patterns SAST misses (stored procs, dynamic dispatch)
// • Manual review catches business-logic injection (search with quoted identifiers)
// • Together: defense in depth

// 8) WAF presence — DAST detects what makes it through
// If a WAF is in front, DAST may pass even with buggy code.
// Test BOTH paths:
//   • Direct to origin (internal IP) → finds real bugs
//   • Via WAF (public URL) → measures WAF effectiveness
// Don't rely on WAF as the only protection.

// 9) Rules of engagement (RoE) checklist
// Before scanning:
//   • Written authorisation from system owner
//   • Scope: endpoints, time windows, account credentials
//   • Exclusions: destructive endpoints, third-party widgets, payment flows
//   • Stop conditions: high CPU on target, data corruption, customer impact
//   • Comms: who to notify if you find something critical
//   • Logging: keep raw output for evidence
//   • Cleanup: delete any test artifacts created

// 10) Common DAST commands reference
sqlmap --tamper=apostrophenullencode    --random-agent     # bypass naive filters
sqlmap --proxy=http://burp:8080 -p id -u 'https://...'      # route through Burp for inspection
sqlmap --crawl=2 -u 'https://...' --batch                    # crawl 2 levels + scan
sqlmap --form -u 'https://.../login' --batch                 # auto-detect form params
sqlmap --data='username=admin&password=foo'                  # POST body
sqlmap --headers='X-API-Token: …'                            # custom headers
sqlmap --identify-waf                                          # detect WAF
sqlmap --eta                                                    # show ETA per technique

// 11) Burp Suite Pro — interactive testing
// • Intruder for parameter fuzzing
// • Repeater for iterating payloads with response diffs
// • Logger++ to see what's actually being sent
// • Active Scan to enumerate possible vulnerabilities
// Best for cases sqlmap can't model (complex auth, GraphQL, stateful flows)

// 12) GraphQL SQLi
// GraphQL endpoints can be injection-vulnerable too. Tools:
//   • InQL extension for Burp
//   • Apollo's introspection on/off settings
// Test the resolvers' DB queries with payloads in arguments + variables.

// 13) Stored / second-order SQLi — DAST often misses
// • Insert into form A; observe behaviour in form B that reads back the field
// • Requires multiple requests; not always covered by automated scanners
// • Manually craft: store, then query, then check error/timing on the second endpoint

// 14) Reporting findings
// Per finding include:
//   • Endpoint, method, parameter
//   • Detection technique (boolean, time-based)
//   • DBMS fingerprint
//   • Risk (data extraction proven? RCE possible?)
//   • Reproduction (curl one-liner)
//   • Suggested fix mapped to code
//   • CWE-89 + OWASP A03:2021 references

// 15) Common bugs / mistakes
// • Scanning production without authorisation → criminal liability in many jurisdictions
// • Running --dump against real customer data → breaches even if 'just to confirm'
// • Forgetting to scope sqlmap to specific params → noisy + slow
// • Treating no findings as proof of safety — many bugs require business context
// • Letting DAST scans destroy data (--os-shell, --file-write) — use on isolated test DB only
// • Sharing raw scan output containing PII → redact before publishing
// • Skipping the WAF bypass test → both layers must be checked
// • Not validating fixes by re-scanning → bugs declared fixed without verification

// sqlmap is the industry standard probe (use only with permission, on staging).
// Schedule against a non-prod environment as part of release tests.