ssrf

What this skill does

# Server-Side Request Forgery (A10:2021)

Analyze source code for server-side request forgery vulnerabilities including URL
fetching from user input, missing URL validation, internal network access, redirect
following, DNS rebinding, and cloud metadata endpoint access. SSRF is especially
critical in cloud environments where metadata endpoints expose credentials and
instance configuration.

## Supported Flags

Read `../../shared/schemas/flags.md` for the full flag specification. This skill
supports all cross-cutting flags. Key flags for this skill:

- `--scope` determines which files to analyze (default: `changed`)
- `--depth standard` reads code and checks URL fetch calls for user-controlled input
- `--depth deep` traces URL input from request parameters through all transformations to fetch calls
- `--severity` filters output (SSRF to cloud metadata is `critical`, general SSRF is `high`)

## Framework Context

Read `../../shared/frameworks/owasp-top10-2021.md`, section **A10:2021 - Server-Side
Request Forgery (SSRF)**, for the full category description, common vulnerabilities,
and prevention guidance.

Key CWEs in scope:
- CWE-918: Server-Side Request Forgery (SSRF)
- CWE-441: Unintended Proxy or Intermediary
- CWE-601: URL Redirection to Untrusted Site (open redirect enabling SSRF chains)

## Detection Patterns

Read `references/detection-patterns.md` for the full catalog of code patterns,
search heuristics, language-specific examples, and false positive guidance.

## Workflow

### 1. Determine Scope

Parse flags and resolve the file list per `../../shared/schemas/flags.md`.
Filter to files likely to contain outbound HTTP request logic:

- HTTP client usage (`**/http/**`, `**/client/**`, `**/fetch/**`, `**/request/**`)
- Webhook and callback handlers (`**/webhooks/**`, `**/callbacks/**`)
- Proxy and gateway code (`**/proxy/**`, `**/gateway/**`)
- Integration modules (`**/integrations/**`, `**/connectors/**`, `**/services/**`)
- File import/upload handlers (`**/upload/**`, `**/import/**`)
- URL preview or unfurling code (`**/preview/**`, `**/unfurl/**`, `**/embed/**`)
- PDF generation and screenshot services (`**/pdf/**`, `**/screenshot/**`, `**/render/**`)

### 2. Check for Available Scanners

Detect scanners per `../../shared/schemas/scanners.md`:

1. `semgrep` -- primary scanner for SSRF patterns (taint analysis for URL flow)
2. `bandit` -- Python-specific request patterns
3. `gosec` -- Go HTTP client patterns

Record which scanners are available and which are missing.

### 3. Run Scanners (If Available)

If semgrep is available, run with rules targeting SSRF:
```
semgrep scan --config auto --json --quiet <target>
```
Filter results to rules matching SSRF, URL fetching, and request forgery patterns.
Normalize output to the findings schema.

### 4. Claude Code Analysis

Regardless of scanner availability, perform manual code analysis:

1. **URL from user input**: Find HTTP client calls (fetch, requests, http.get, etc.)
   and trace whether the URL or any URL component originates from user input
   (query params, request body, headers, path params).
2. **URL scheme validation**: Check that URL schemes are restricted to `http://` and
   `https://` only, blocking `file://`, `gopher://`, `dict://`, `ftp://`, and other
   dangerous schemes.
3. **Internal IP blocking**: Verify that URLs are validated against internal/private IP
   ranges (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16,
   0.0.0.0, ::1, fd00::/8) before making requests.
4. **Cloud metadata protection**: Check for blocking of cloud metadata endpoints
   (169.254.169.254, metadata.google.internal, 169.254.170.2) and IMDSv2 enforcement
   on AWS.
5. **Redirect handling**: Verify that HTTP redirects are either disabled or validated
   at each hop to prevent redirect-based SSRF bypass.
6. **DNS rebinding**: Check if DNS resolution and connection happen atomically or if
   there is a TOCTOU gap where a hostname could resolve to a safe IP during validation
   but a private IP during the actual request.

When `--depth deep`, additionally trace:
- Complete data flow from request parameter to HTTP client call
- URL construction through string concatenation, template rendering, or URL builder APIs
- Indirect SSRF via PDF generators, screenshot services, SVG/XML processors, or webhook URLs

### 5. Report Findings

Format output per `../../shared/schemas/findings.md` using the `SSRF` prefix
(e.g., `SSRF-001`, `SSRF-002`).

Include for each finding:
- Severity and confidence
- Exact file location with code snippet
- Impact description specific to the SSRF scenario (cloud metadata, internal scanning, data exfiltration)
- Concrete fix with diff when possible
- CWE and OWASP references

## What to Look For

These are the high-signal patterns specific to server-side request forgery. Each
maps to a detection pattern in `references/detection-patterns.md`.

1. **URL from user input passed to HTTP client** -- Any HTTP request function
   (fetch, requests.get, http.Get, HttpClient) called with a URL that originates
   from user-controlled input without validation.

2. **Missing URL scheme whitelist** -- URL validation that does not restrict the
   scheme to http/https, allowing file://, gopher://, or other dangerous protocols.

3. **No blocking of internal IP ranges** -- Outbound requests to user-supplied URLs
   without checking the resolved IP against private/reserved ranges, enabling
   internal network scanning and service access.

4. **Cloud metadata endpoint accessible** -- No specific blocking of 169.254.169.254
   (AWS/Azure/GCP metadata), metadata.google.internal, or 169.254.170.2 (ECS task
   metadata), allowing credential theft from cloud environments.

5. **Redirect following on user-supplied URLs** -- HTTP client configured to follow
   redirects when fetching user-supplied URLs, enabling attackers to bypass URL
   validation by redirecting from an allowed domain to an internal target.

6. **DNS rebinding vulnerability** -- URL validation resolves the hostname to check
   the IP, but the actual HTTP request resolves it again, allowing a DNS record
   with a short TTL to return a different (internal) IP on the second resolution.

7. **Indirect SSRF via document processors** -- PDF generators (wkhtmltopdf, Puppeteer),
   SVG renderers, XML parsers (XXE), or webhook registration endpoints that fetch
   URLs without SSRF protection.

## Scanner Integration

| Scanner | Coverage | Command |
|---------|----------|---------|
| semgrep | URL from user input, taint tracking through request calls | `semgrep scan --config auto --json --quiet <target>` |
| bandit | Python requests/urllib with user input | `bandit -r <target> -f json -q` |
| gosec | Go net/http with user input | `gosec -fmt json ./...` |

**Fallback (no scanner)**: Use Grep with patterns from `references/detection-patterns.md`
to find HTTP client calls, URL construction from user input, and missing validation.
Report findings with `confidence: medium`.

Relevant semgrep rule categories:
- `python.requests.security.ssrf.*`
- `python.urllib.security.audit.ssrf.*`
- `javascript.fetch.security.ssrf.*`
- `java.net.security.audit.ssrf.*`
- `go.net.security.audit.ssrf.*`

## Output Format

Use the findings schema from `../../shared/schemas/findings.md`.

- **ID prefix**: `SSRF` (e.g., `SSRF-001`)
- **metadata.tool**: `ssrf`
- **metadata.framework**: `owasp`
- **metadata.category**: `A10`
- **references.owasp**: `A10:2021`
- **references.stride**: `I` (Information Disclosure) or `E` (Elevation of Privilege)

Severity guidance for this category:
- **critical**: SSRF to cloud metadata endpoint (169.254.169.254), unauthenticated endpoint with no URL validation
- **high**: SSRF to internal network with no IP range blocking, redirect following enabled on user URLs
- **medium**: Partial URL validation (scheme checked but IP not validated), DNS rebinding possible
- **low**: SSRF risk in internal-only service not exposed to external