Add VitePress documentation site with complete user guides
Covers getting started, repositories, scanning, findings, configuration, SBOM, code graph, impact analysis, DAST, AI chat, issue tracker integration, Docker deployment, environment variables, Keycloak auth, and OpenTelemetry. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
112
docs/features/dast.md
Normal file
112
docs/features/dast.md
Normal file
@@ -0,0 +1,112 @@
|
||||
# DAST Scanning
|
||||
|
||||
DAST (Dynamic Application Security Testing) performs black-box security testing against live web applications and APIs. Unlike SAST which analyzes source code, DAST tests running applications by sending crafted requests and analyzing responses.
|
||||
|
||||
## DAST Overview
|
||||
|
||||
Navigate to **DAST** in the sidebar to see the overview page with:
|
||||
|
||||
- Total DAST scans performed
|
||||
- Total DAST findings discovered
|
||||
- Number of active targets
|
||||
- Recent scan run history with status, phase, and finding counts
|
||||
|
||||
## Managing Targets
|
||||
|
||||
Navigate to **DAST > Targets** to configure applications to test.
|
||||
|
||||
### Adding a Target
|
||||
|
||||
1. Enter a **target name** (descriptive label)
|
||||
2. Enter the **base URL** (e.g. `https://staging.example.com`)
|
||||
3. Click **Add Target**
|
||||
|
||||
### Target Configuration
|
||||
|
||||
Each target supports these settings:
|
||||
|
||||
| Setting | Description | Default |
|
||||
|---------|-------------|---------|
|
||||
| **Target Type** | WebApp, REST API, or GraphQL | WebApp |
|
||||
| **Max Crawl Depth** | How many link levels to follow | 5 |
|
||||
| **Rate Limit** | Maximum requests per second | 10 |
|
||||
| **Destructive Tests** | Allow DELETE/PUT requests | No |
|
||||
| **Excluded Paths** | URL paths to skip during testing | — |
|
||||
|
||||
### Authentication
|
||||
|
||||
DAST supports authenticated scanning with multiple methods:
|
||||
|
||||
| Method | Configuration |
|
||||
|--------|--------------|
|
||||
| **None** | No authentication |
|
||||
| **Basic** | Username and password (HTTP Basic Auth) |
|
||||
| **Bearer** | Bearer token (Authorization header) |
|
||||
| **Cookie** | Session cookie value |
|
||||
| **Form** | Login URL, username field, password field, and credentials |
|
||||
|
||||
::: warning
|
||||
Authenticated scans access more of the application surface. Only test applications you own or have explicit authorization to test.
|
||||
:::
|
||||
|
||||
## Running a DAST Scan
|
||||
|
||||
Click the **Scan** button on any target row. The scan runs through these phases:
|
||||
|
||||
1. **Crawl** — Discovers pages, forms, and API endpoints by following links and analyzing JavaScript
|
||||
2. **Test** — Sends attack payloads to discovered parameters
|
||||
3. **Report** — Collects results and generates findings
|
||||
|
||||
The scan uses a headless Chromium browser (the `chromium` service in Docker Compose) for JavaScript rendering during crawling.
|
||||
|
||||
## DAST Scan Agents
|
||||
|
||||
The scanner includes specialized testing agents:
|
||||
|
||||
### API Fuzzer
|
||||
Tests API endpoints with malformed inputs, boundary values, and injection payloads.
|
||||
|
||||
### XSS Scanner
|
||||
Detects Cross-Site Scripting vulnerabilities by injecting script payloads into form fields, URL parameters, and headers.
|
||||
|
||||
### SSRF Scanner
|
||||
Tests for Server-Side Request Forgery by injecting internal URLs and cloud metadata endpoints into parameters.
|
||||
|
||||
### Auth Bypass Scanner
|
||||
Tests for authentication and authorization bypass by manipulating tokens, sessions, and access control headers.
|
||||
|
||||
## DAST Findings
|
||||
|
||||
Navigate to **DAST > Findings** to see all discovered vulnerabilities.
|
||||
|
||||
### Finding List
|
||||
|
||||
Each finding shows:
|
||||
|
||||
| Column | Description |
|
||||
|--------|-------------|
|
||||
| Severity | Critical, High, Medium, or Low |
|
||||
| Type | Vulnerability category (SQL Injection, XSS, SSRF, etc.) |
|
||||
| Title | Description of the vulnerability |
|
||||
| Endpoint | The HTTP path that is vulnerable |
|
||||
| Method | HTTP method (GET, POST, PUT, DELETE) |
|
||||
| Exploitable | Whether the vulnerability was confirmed exploitable |
|
||||
|
||||
### Finding Detail
|
||||
|
||||
Click a finding to see full details:
|
||||
|
||||
- **Vulnerability type** and CWE identifier
|
||||
- **Endpoint URL** and HTTP method
|
||||
- **Parameter** that is vulnerable
|
||||
- **Exploitability** — Confirmed or Unconfirmed
|
||||
- **Description** — What the vulnerability is and why it matters
|
||||
- **Remediation** — How to fix the issue
|
||||
- **Evidence** — One or more request/response pairs showing:
|
||||
- The crafted HTTP request (method, URL, headers)
|
||||
- The payload that triggered the vulnerability
|
||||
- The HTTP response status and relevant snippet
|
||||
|
||||
::: tip
|
||||
Findings marked as **Confirmed** exploitable were verified by the scanner with a successful attack. **Unconfirmed** findings show suspicious behavior that may indicate a vulnerability but could not be fully exploited.
|
||||
:::
|
||||
Reference in New Issue
Block a user