Find SSRF in HTTP Parameters

Overview

Server-side request forgery is invisible from the outside. The response looks normal whether or not the server made the request you asked it to, so the bug sits in production until somebody thinks to test for it with a callback. That is also why it survives code review: the parameter looks like a URL because it is supposed to be one.

This finds the parameters that take a URL and tests each with out-of-band detection, so a finding means the server actually reached out. You get the reachable endpoints, the parameter that carried the payload, and the interaction that proves it, which is the evidence a developer needs to accept the ticket. Scheduling it makes it part of continuous security testing rather than a one-off engagement.

Pipeline

1. Read the target.
2. katana crawls the live application and collects endpoints.
3. gauplus adds URLs from public archives, including pages the crawl cannot reach.
4. Both sources merge into one candidate set.
5. nuclei runs its DAST SSRF templates against every candidate with out-of-band interaction detection.
6. Confirmed interactions are written to a PDF report.

Inputs

• Target. One application. It seeds both sources, the live crawl and the archive lookup, so you do not maintain a URL list alongside it.
• Out-of-band detection. nuclei runs with interaction detection on, and that default is the point of the workflow. A finding is an interaction that arrived, not a response body that looked unusual.
• Template set. The DAST SSRF templates, not the whole nuclei library. Keeping the set narrow is what stops a parameter test from turning into a general vulnerability scan you did not schedule time for.

Outputs

• A PDF report. Confirmed interactions only, each with the endpoint, the parameter that carried the payload, and the interaction record that proves the server reached out. That is the evidence a developer needs to accept the ticket.
• A merged endpoint set. The union of the crawl and the archive, deduplicated, which is a reusable candidate list for any other parameter testing on the same target.
• The crawl and archive sets on their own. Each collector's output lands separately, so you can see which pages the crawl never reached.

Sample output

Crawling and archive mining produce different URL sets, and the union is what gets tested:

url	param	source
https://example.com/fetch?url=https://internal	url	crawl
https://example.com/proxy?target=127.0.0.1	target	crawl
https://api.example.com/webhook?callback=https://attacker.example.com	callback	archive
https://dev.example.com/import?src=http://169.254.169.254	src	archive
https://example.com/preview?link=https://metadata.example.com	link	crawl

Detection is out-of-band, so the report lists the interaction that arrived rather than a response body that looked unusual. That distinction is what makes these findings straightforward to reproduce.

FAQ

Do I need to run my own callback server?

No. The out-of-band interaction detection built into nuclei provides the listener, and the interactions it records are what the report is built from. You do not stand anything up.

Why not just read the response?

Because the response is the same either way. A server that fetched your URL and one that ignored it can return identical bodies, which is exactly why this bug survives code review and why detection has to happen out of band.

Is it safe to run against a third party?

Archive mining reads public data and touches nothing. The crawl and the payload delivery are traffic to the target, and an SSRF payload asks their server to make a request on your behalf, which is an action inside their network rather than a read of it. Run those only with authorization.

How is this different from running nuclei myself?

nuclei needs URLs. Producing them is most of this workflow, crawling the live application and recovering from archives the pages a crawl cannot reach, then merging both into one candidate set. The template run is the last step.

What does running it on a schedule buy?

New parameters. Every release adds endpoints, and a parameter that takes a destination is the kind of thing that ships without anyone flagging it. Running after each deploy catches it while the change is still fresh in someone's memory.

Related workflows

• Find Reflected XSS on a Domain. Reach for this instead when the parameter is reflected back to the user rather than fetched by the server.
• Find Open Redirects on a Domain. Reach for this instead when the server hands the URL to the browser rather than requesting it. Same parameter shape, different sink.
• API IDOR and BOLA Scanner. Reach for this instead when there is an OpenAPI spec, because enumerating it beats crawling for parameters.