hunt-ssrf

Validates server-side URL fetching for SSRF using controlled OAST callbacks.

10|3|Updated Aug 10, 2026
One-click install
npx skills add https://github.com/baiqigo/baiqi-redteam-lab --skill hunt-ssrf-baiqigo
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: hunt-ssrf
Source: https://github.com/baiqigo/baiqi-redteam-lab/tree/main/.agents/skills/hunt-ssrf
Command: npx skills add https://github.com/baiqigo/baiqi-redteam-lab --skill hunt-ssrf-baiqigo

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? It provides an evidence-gated workflow for confirming whether an application performs server-side URL fetches (SSRF) without risking internal network access, metadata endpoints, or third-party systems. ## Core Features & Use Cases - Engagement Gating: Requires declared authorization, locked scope, and established host/identity/path baselines before any probe runs. - Minimal Safe Validation: Uses a single controlled HTTPS/DNS OAST canary compared against a normal URL to confirm server-side reachability, redirect, and allowlist behavior. - Strict Oracle Rules: Only attributable, repeatable OAST callbacks count as evidence; WAF blocks, timeouts, DNS cache hits, and error text are treated as inconclusive. - Use Case: When a webhook URL or image proxy parameter appears in an authorized assessment, use this Skill to verify the server actually fetches the URL via your own OAST listener, then route confirmed impact chains to chain-review. ## Quick Start Use hunt-ssrf to plan an evidence-gated, authorized validation path for a suspected server-side URL fetch parameter.

Frequently Asked Questions about hunt-ssrf

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I test for SSRF vulnerabilities safely?

Test SSRF safely by sending a single controlled HTTPS or DNS OAST canary URL and comparing it against a normal URL baseline. Confirm the callback is attributable to the server by task ID, timing, and request fingerprint, and never target internal or metadata addresses.

What is an OAST callback in SSRF testing?

An OAST callback is an out-of-band interaction where the target server contacts a listener you control, proving server-side fetching occurred. Valid evidence requires the callback to be attributable, repeatable, and correlated with your probe's task ID and timing.

Why is my SSRF test result inconclusive?

Results are inconclusive when WAF blocks, captchas, timeouts, single errors, or scanner hits occur, since these do not prove server-side fetching. Client-side browser requests, DNS cache hits, and error message text also do not qualify as valid SSRF evidence.

What targets are off-limits during SSRF validation?

Loopback addresses, private networks, link-local addresses, cloud metadata endpoints, and file or gopher protocols are prohibited destinations. Internal scanning, port probing, protocol upgrades, and redirects to third parties are explicit stop conditions.

When should SSRF findings be escalated further?

Confirmed impact chains must be routed to a chain-review process rather than automatically escalated to remote code execution. Save the input, task ID, OAST timeline, and baseline as evidence before any further analysis.