exploiting-ssrf-and-open-redirect

Confirms SSRF and open redirect vulnerabilities via OOB canary callbacks and Location header analysis.

Updated Jun 24, 2026
One-click install
npx skills add https://github.com/bs-koo/gx-security --skill exploiting-ssrf-and-open-redirect-bs-koo
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: exploiting-ssrf-and-open-redirect
Source: https://github.com/bs-koo/gx-security/tree/main/skills/exploiting-ssrf-and-open-redirect
Command: npx skills add https://github.com/bs-koo/gx-security --skill exploiting-ssrf-and-open-redirect-bs-koo

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve? Static scanners flag SSRF and open redirect candidates but cannot prove they are actually exploitable. This Skill dynamically confirms exploitability against a running staging or local target: it proves blind SSRF by receiving an out-of-band callback and proves open redirects by inspecting the Location response header. ## Core Features & Use Cases - OOB Canary SSRF Confirmation: Spins up a loopback HTTP listener, injects a unique canary URL into the target parameter, and confirms server-side request forgery when the callback arrives — even for blind SSRF with no visible response. - Open Redirect Verification: Fires six bypass variants (absolute URL, scheme-relative, backslash, userinfo, prefix bypass) at redirect parameters and flags the endpoint vulnerable when the Location header points to an external host. - Fail-Closed Safety Gate: Every launch passes through scope_guard, which blocks production and public targets at the code level; all probes are non-destructive GET injections. - Use Case: After a static scan flags a suspicious returnUrl parameter on a Spring Boot login page, run this Skill against the local staging instance to confirm whether returnUrl=https://evil.test actually produces a 302 redirect to an external domain. ## Quick Start Run the attack script against my local staging app at http://localhost:7171 to test the login returnUrl for open redirect and the /api/v1/proxy url parameter for SSRF.

Frequently Asked Questions about exploiting-ssrf-and-open-redirect

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

FAQPage Schema
How do I confirm a blind SSRF vulnerability dynamically?▼

Start an out-of-band canary listener on loopback, inject its unique nonce URL into the target parameter, and fire a GET request. If the server makes an internal request, the listener receives the callback, confirming SSRF even when the response shows nothing.

How to test open redirect vulnerabilities in a login returnUrl parameter?▼

Inject external-domain payload variants such as absolute HTTPS, scheme-relative, backslash, and userinfo forms into the redirect parameter, then check whether the response Location header points outside the base host. Six variants are tested to bypass naive startsWith filters.

Does SSRF testing work when the app runs in a Docker container?▼

Yes, but the canary advertise host must be set to host.docker.internal so the container can reach the listener on the host machine. The listener itself always binds to 127.0.0.1; the advertise host is only the address given to the target app.

Why does SSRF show callback false even though static analysis flagged it?▼

A missed callback means dynamically unconfirmed, not safe. The app may issue requests asynchronously, be network-isolated from the canary host, or run in Docker without the correct advertise host. The static suspicion remains and is reported as static-only confidence.

Can this penetration test run against production servers?▼

No. The scope_guard safety gate runs fail-closed before every launch and blocks production, public, and IP-spoofed targets at the code level, exiting with an error. Only authorized, isolated staging or local environments are permitted.