const dns = require('dns').promises; const ip = await dns.lookup(urlObj.hostname); if (isPrivateIP(ip.address)) throw new Error('Blocked'); The SSRF vulnerability in OWASP Juice Shop is small but elegant. It demonstrates a single line of missing validation leading to a complete breach of network segmentation. For penetration testers, mastering SSRF means understanding that the server is just another user—one with far more privileges.
POST /api/image/uploads HTTP/1.1 Host: juice-shop.local Content-Type: application/json "url": "http://localhost:3000/some/path"
But the real SSRF is not directly in the Order ID. It's in the or "Complaint" feature, depending on the version. In the standard Juice Shop SSRF challenge, the vulnerable endpoint is: juice shop ssrf
"url": "file:///etc/passwd" Juice Shop's Node.js request module does follow file:// by default, but older urllib or curl wrappers do. Defenses: How to Kill SSRF Juice Shop is vulnerable by design. Here is how to fix it in production: 1. Allowlist, Never Blocklist const ALLOWED_DOMAINS = ['maps.googleapis.com', 'trusted-cdn.com']; const urlObj = new URL(userUrl); if (!ALLOWED_DOMAINS.includes(urlObj.hostname)) return res.status(403).send('Domain not allowed');
(Note: Exact path varies by version; check the challenge description in Juice Shop). SSRF is rarely an end in itself. In Juice Shop, it's a proof-of-concept, but in real systems, combine SSRF with other vulnerabilities: 1. Cloud Metadata Extraction If Juice Shop were deployed on AWS with a misconfigured IMDSv1: const dns = require('dns')
If the server responds with a successful fetch (even an error from the local service), the SSRF exists. Juice Shop's base configuration has no whitelist. But in hardened real-world apps, you might see filters. Practice bypass techniques:
Juice Shop downloads this image server-side and then serves it to the client. The parameter center (the address) is partially user-influenced via the order database. POST /api/image/uploads HTTP/1
); );