Thilan Dissanayaka Application Security April 06, 2020

Server-Side Request Forgery

SSRF (Server-Side Request Forgery) is a type of security vulnerability where an attacker tricks a server into making a request to another internal or external system that the attacker shouldn’t have access to. Note the point that this request is not possible to make directly therefor the attacker is using the victim server to make that request on behalf of him.

In short,

The attacker doesn’t send the request directly to the target — they fool the server into sending it on their behalf.

How It Works

Imagine you call a hotel and say:

“Hey, can you call this other room for me and tell me what the person says?”

Now, what if you gave the front desk a number outside the hotel, like a secret government number? And the hotel doesn’t check and just dials it?

You’ve now abused the hotel’s phone system to call somewhere you couldn’t call directly.

That’s SSRF — using the server like a middleman to reach places you shouldn’t be allowed to.

A Common Example

Let’s say there’s a website that lets users give a URL to fetch a profile picture:

GET /fetch-image?url=http://example.com/pic.jpg

The server reads the url parameter and downloads the image from that link.

What if an attacker change the url parameter to the following?

http://127.0.0.1:8000/admin

Then the complete payload becomes,

GET /fetch-image?url=http://127.0.0.1:8000/admin

Now the server makes a request to itself or another internal service — and returns the result to the attacker. That internal page was never meant to be seen from the outside!

What Can Attackers Do with SSRF?

Access internal-only websites or APIs
Bypass firewalls or IP restrictions
Read cloud metadata (e.g., AWS http://169.254.169.254/)
Perform port scans from inside the network
Escalate to Remote Code Execution (RCE) if other bugs exist

Real-World Danger

In cloud environments like AWS, SSRF can be very dangerous.

Attackers may access:

http://169.254.169.254/latest/meta-data/

Which gives them access to:

Instance credentials
Tokens
Configuration secrets

That could lead to full cloud account takeover.

Types of SSRF

Type	Description
Basic SSRF	Directly manipulate a parameter to control server-side requests.
Blind SSRF	The attacker can trigger a request, but does not see the response.
Recursive SSRF	The SSRF leads to an internal request that in turn triggers more requests.
File-based SSRF	SSRF used to access file system protocols (e.g., `file://`, `gopher://`)

How to Prevent SSRF

Don’t let users supply raw URLs to the server.
Use allow-lists: only let the server connect to specific safe domains.
Block requests to:

localhost, 127.0.0.1, 169.254.169.254, Internal IP ranges like 10.0.0.0/8, 192.168.0.0/16

Disable unnecessary outbound network access from servers.
Use network segmentation.
Sanitize and validate user input carefully.

SSRF Prevention Strategies

Input Validation Allowlist only specific, known URLs or domains.

const allowedDomains = ['https://api.myservice.com'];

Block Internal IP Ranges Block requests to:

127.0.0.1, 0.0.0.0, 169.254.169.254

Private IPs: 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12

DNS Resolution + IP Verification Resolve domain names and check that the resulting IP isn’t internal.
Disable unused protocols If your app doesn’t need gopher://, file://, etc., block them.
Network layer defenses Firewalls and service mesh rules (e.g., Istio) to restrict egress traffic.
Cloud-specific controls On AWS, disable metadata v1, use IMDSv2, and apply IAM policies.