# SSRF via 'Insert Image' feature of Products/Collections/Frontpage

Shopify's Insert Image URL fetch validated scheme/port but followed redirects, enabling SSRF port scanning of internal and arbitrary hosts via response codes.

- Payout: hidden
- Severity: medium
- Program: Shopify
- Found by: alpha
- Disclosed: 2015-08-24
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/67389
- Library page: https://bugbountylibrary.com/r/h1%3A67389
- Tags: area:web domain:web impact:internal-access kind:bounty platform:hackerone sev:medium tech:rest technique:chained vuln:ssrf

**Target:** /admin/settings/files.json image-fetch endpoint
**Root cause:** The src URL was validated for scheme and port only on the initial URL; the server followed HTTP redirects to a second URL without re-validating scheme/port, allowing arbitrary host/port fetches.
**Steps:**
1. Send `POST /admin/settings/files.json` with `src=SOME_URL`; non-http(s) schemes or non-standard ports return 422.
2. Host a redirector at `http://hettoteam.tk/r.php?r=http://hettoteam.tk:21` that 302s to the target URL.
3. Submit `src=http%3A%2F%2Fhettoteam.tk/r.php?r=http://scanme.nmap.org:1` → 422 (port closed).
4. Submit `src=http%3A%2F%2Fhettoteam.tk/r.php?r=http://scanme.nmap.org:22` → 500 (port open).
**How found:** Recalled a prior SSRF (bug 67377) with the same filter, hypothesized the scheme/port check only applied to the first URL, and used a self-hosted redirect to reach restricted ports.
**Exploitation:** Attacker supplies a redirector URL as src; Shopify's fetcher follows the redirect to an arbitrary host:port, and the HTTP response code (500 vs 422) leaks whether the port is open, enabling internal network and loopback port scanning from Shopify infrastructure.
**Insight:** When a URL fetcher rejects bad schemes/ports, test whether the check runs only on the initial URL — a redirect to a disallowed port often bypasses it, and differential response codes (500 vs 422) turn it into a port scanner.

