How do I install the Web Ssrf skill?

Run npx skillmds@latest add noorqureshi/web-ssrf in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Web Ssrf safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Web Ssrf?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Web Ssrf free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Web Ssrf?

NoorQureshi (@noorqureshi) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Web Ssrf by noorqureshi — Agent Skill

Name: Web Ssrf
Author: NoorQureshi

Web Ssrf

Discover and escalate Server-Side Request Forgery. Load when the app fetches a URL you influence: webhooks, "import from URL", link/image preview, PDF/HTML render, avatar-by-URL, URL health-checks, XML/SVG parsers. Signals: params like url=, uri=, dest=, callback=, image=, feed=, or a request that reaches out on your behalf.

NoorQureshi dab72ee 2.2 KB Updated Sep 17, 2026

File contents

Server-Side Request Forgery (SSRF)

When it applies

The server makes an outbound request to a destination you control or influence. Even a "blind" fetch (no response shown) is useful if you can see the callback and reach internal services.

Why it works

The request originates from inside the trust boundary, so it bypasses network ACLs and hits things you can't reach directly: cloud metadata, internal admin panels, databases, other microservices — often unauthenticated because they "only accept internal traffic".

Method

Confirm with an out-of-band beacon: point the param at your interactsh/Collaborator host and watch for the DNS/HTTP hit. DNS-only hit = blind SSRF (still valuable).
Map internal reach: try http://127.0.0.1:<port>/, http://localhost, and the cloud metadata IP 169.254.169.254. Fuzz ports to find live internal services.
Escalate by target:
- Cloud metadata → steal IAM creds (see cloud-imds-ssrf).
- Internal line-protocol service (Redis/6379, memcached) → RCE via gopher:// (see web-ssrf-gopher-redis-rce).
- Internal HTTP admin → hit unauthenticated actions.
Bypass filters blocking localhost/private IPs: decimal/octal/hex IPs (http://2130706433/), [::], 127.0.0.1.nip.io, DNS-rebinding, @-tricks (http://expected.com@attacker.com), and redirect chains (allowed host 302s to internal).

Gotchas

Allowlist on scheme/host is often only on the first request — a 30x redirect slips past.
SSRF via SVG/<image>/PDF renderers and via Location/webhook retries is easy to miss.
No response body ≠ no vuln: timing and OOB confirm blind SSRF.

Verify success

OOB callback from the target's egress IP, or a response revealing an internal-only resource (metadata JSON, an internal 200/redirect you shouldn't reach).

References

PortSwigger SSRF labs; Orange Tsai "A New Era of SSRF".

---name: web-ssrfdescription: Discover and escalate Server-Side Request Forgery. Load when the app fetches a URL you influence: webhooks, "import from URL", link/image preview, PDF/HTML render, avatar-by-URL, URL health-checks, XML/SVG parsers. Signals: params like url=, uri=, dest=, callback=, image=, feed=, or a request that reaches out on your behalf.---# Server-Side Request Forgery (SSRF)## When it appliesThe server makes an outbound request to a destination you control or influence. Even a"blind" fetch (no response shown) is useful if you can see the callback and reach internalservices.## Why it worksThe request originates from inside the trust boundary, so it bypasses network ACLs and hitsthings you can't reach directly: cloud metadata, internal admin panels, databases, othermicroservices — often unauthenticated because they "only accept internal traffic".## Method1. **Confirm** with an out-of-band beacon: point the param at your `interactsh`/Collaborator host and watch for the DNS/HTTP hit. DNS-only hit = blind SSRF (still valuable).2. **Map internal reach**: try `http://127.0.0.1:<port>/`, `http://localhost`, and the cloud metadata IP `169.254.169.254`. Fuzz ports to find live internal services.3. **Escalate by target**: - **Cloud metadata** → steal IAM creds (see `cloud-imds-ssrf`). - **Internal line-protocol service** (Redis/6379, memcached) → RCE via `gopher://` (see `web-ssrf-gopher-redis-rce`). - **Internal HTTP admin** → hit unauthenticated actions.4. **Bypass filters** blocking `localhost`/private IPs: decimal/octal/hex IPs (`http://2130706433/`), `[::]`, `127.0.0.1.nip.io`, DNS-rebinding, `@`-tricks (`http://expected.com@attacker.com`), and redirect chains (allowed host 302s to internal).## Gotchas- Allowlist on scheme/host is often only on the *first* request — a 30x redirect slips past.- SSRF via SVG/`<image>`/PDF renderers and via `Location`/webhook retries is easy to miss.- No response body ≠ no vuln: timing and OOB confirm blind SSRF.## Verify successOOB callback from the target's egress IP, or a response revealing an internal-only resource(metadata JSON, an internal 200/redirect you shouldn't reach).## ReferencesPortSwigger SSRF labs; Orange Tsai "A New Era of SSRF".

Frequently asked questions