Web Security · Cloud

SSRF on AWS: From a URL Parameter to Instance Credentials

How a simple "download this image" feature can leak AWS credentials, why three common fixes don't work, and what does.

By Mohammad Arif · 13 min read

Server-side request forgery (SSRF) is easy to describe and easy to get wrong. This post follows one real-looking endpoint through three attempts to fix it. The pattern is almost always the same: the fix checks one thing, and the server then does something slightly different.

1. The setup

An image service runs on an EC2 instance. You send it a URL, it downloads the image, processes it, and saves the result to S3.

POST /api/v1/process-image

{ "image_url": "https://example.com/photo.jpg" }

In a security review you find that the server requests whatever URL you give it. The developer says:

"We check that the URL starts with http:// or https://, and we only accept JPEG and PNG files. So it's secure."

2. What's wrong

The user decides where the server connects. That is the whole bug. The server sits inside your network, so internal services and the EC2 metadata service trust requests from it. An attacker can use the server to reach things they can't reach from the internet.

Figure 1. The request comes from the trusted server, not from the attacker. The credentials reach the attacker only if the response, or an error message, exposes them.

The developer's two checks don't help:

The scheme check limits how the server talks (no file://), but not who it talks to. The metadata service and most internal services are plain HTTP.
The image check happens after the download. The request has already been made, and the way the service rejects a non-image can still leak information.

Also keep two problems apart. SSRF is about the destination. A malicious image that crashes a decoder is about file handling. They need different fixes.

3. Can they really steal AWS credentials?

Not automatically. Reaching the metadata address is only the first step. Ask these questions:

Can the request reach it? The metadata service lives at 169.254.169.254 (and [fd00:ec2::254] if the IPv6 endpoint is on). It can be disabled or blocked.
Is IMDSv1 still allowed? By default an instance accepts both versions unless you configure it. IMDSv1 only needs a plain GET.
Can the attacker see the response? If the service just says "not an image", it is a blind SSRF. They can't read the credentials directly, though errors or timing can still leak things.
What can the role do? Stolen credentials are only as powerful as the instance role. A role that can write to one S3 prefix is a small problem. AdministratorAccess is a big one.

What IMDSv2 changes

With IMDSv2 you first need a token, and you get it with a PUT request plus a special header. Then you send the token in a header on the next request:

# step 1: PUT to get a token
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" \
        -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

# step 2: use the token as a header
curl -H "X-aws-ec2-metadata-token: $TOKEN" \
     http://169.254.169.254/latest/meta-data/iam/security-credentials/

A "fetch this URL" feature only makes a plain GET and doesn't let the attacker set headers, so it can't do step 1. AWS also rejects the token request if it carries an X-Forwarded-For header, and by default the token response can't travel past the instance (hop limit 1).

IMDSv2 makes this attack harder. It does not fix SSRF. A feature that lets the attacker choose the method and headers and read the reply would still work. And IMDSv2 does nothing to protect other internal services.

This isn't just theory. The 2019 Capital One breach, as publicly reported, involved SSRF against the metadata service. That was before IMDSv2.

4. Three attempts to fix it

Attempt 1: check the scheme and the file type

This is what the developer proposed. As shown above, it doesn't control where the server connects, so it fixes nothing.

Attempt 2: resolve the hostname and block private IPs

def fetch_image(url):
    parsed = urlparse(url)
    if parsed.scheme not in ["http", "https"]:
        raise ValueError("Invalid scheme")

    ip = socket.gethostbyname(parsed.hostname)     # lookup 1: used for the check
    if not ipaddress.ip_address(ip).is_global:
        raise ValueError("Internal IP blocked")

    return requests.get(url, timeout=5,            # lookup 2: used to connect
                        allow_redirects=True).content

This is much better, and the IP check itself is correct. But it checks one address and then connects to another. There are four ways that goes wrong.

1. The name is looked up twice. The check uses the first lookup. requests does its own lookup when it connects. If the attacker controls the DNS for their hostname, they can answer the first lookup with a public IP and the second with 169.254.169.254. The check passed, and the connection still went inside. This is called DNS rebinding. The root cause is that the checked address is never tied to the connection.

2. Redirects. Only the first URL is checked, but redirects are followed. The attacker's public server simply replies 302 with Location: http://169.254.169.254/... and the client follows it with no check.

3. IPv6. Python's docs say gethostbyname() doesn't support IPv6 and recommend getaddrinfo(). The HTTP client looks up both IPv4 and IPv6 and tries every address. A host with a harmless IPv4 record and an IPv6 record pointing to ::1 passes the check and gets connected over IPv6.

4. URL parsing differences. The check reads the host with urlparse. The actual request is parsed by different code inside requests. If two parsers read the same string differently (OWASP's example is http://example.com\@evil.com), the host you checked isn't the host you connect to. OWASP's advice: reject the URL if parsers disagree.

What is not a bypass here: localhost, 0.0.0.0 or writing 127.0.0.1 as 2130706433. This code checks the resolved address, and these all resolve to loopback or similar, which is_global rejects. Odd IP spellings only beat checks that look at the URL text. Only call something a bypass if you can explain why the logic fails.

Attempt 3: turn off redirects and require IMDSv2

This fixes problem 2 and the plain-GET route to credentials. It does not fix problems 1, 3 or 4. Attackers can still use DNS rebinding to reach other internal services, such as an admin page on a private address.

So the honest answer is: SSRF still exists, and this specific credential theft is now much harder. Say both.

5. What a safe version looks like

First ask: does the service really need to fetch any URL? If users can upload the file, accept an upload. If the images come from known sites, use an allowlist, and build the request in your code from the matching entry. That removes the problem instead of managing it.

If you must fetch arbitrary public URLs, contain the risk:

Figure 2. The application check and the network control are independent. If the fetcher is fooled, the network still refuses the connection, and the fetcher has no valuable credentials.

Use a separate fetcher with no useful AWS role. If it is tricked, there is nothing to steal.
Look up once, check every address, connect to that address. Use getaddrinfo to see IPv4 and IPv6. Refuse the request if any address is private. Then connect to the checked IP, but keep the original hostname for the Host header, TLS and certificate checks. (Just swapping the IP into an HTTPS URL breaks certificate checks, so do it at the connection level or use an egress proxy such as Smokescreen.)
Don't follow redirects. Treat any 3xx as an error, or run every check again on each hop.
Block at the network level too. Deny private, loopback, link-local and metadata addresses outside the app. Note that security groups don't filter traffic to the metadata service (AWS says so), so use a host firewall rule, or turn IMDS off on a fetcher with no role.
Limit the download. Stream it, cap the size and total time, and allow only ports 80 and 443.
Handle the image safely. Check the real file type, decode it in an isolated process with size limits, and re-encode it. A valid JPEG header doesn't make a file safe to decode.
Return the same error for every rejection, and never echo fetched content.
Keep the role small. The service that writes to S3 needs PutObject on one prefix and nothing else.

How the safe version fixes each problem

Here is every problem from section 4, what the attacker does, what we change, and why the attack stops working.

Problem 1: the name is looked up twice (DNS rebinding).

Attack: attacker's DNS answers a public IP for our check, then 169.254.169.254 for the real connection.
Fix: we do one lookup and connect to the IP we checked. The HTTP library never gets to look up the name.
Why it works: there is no second lookup left to trick. Changing DNS after our check changes nothing, because we already hold the checked IP.

infos = socket.getaddrinfo(host, port, type=socket.SOCK_STREAM)   # the only lookup
ips = [i[4][0] for i in infos]

if not all(ipaddress.ip_address(ip).is_global for ip in ips):
    raise Rejected()

sock = socket.create_connection((ips[0], port), timeout=5)        # the IP we checked
tls = ctx.wrap_socket(sock, server_hostname=host)                 # HTTPS only: certificate checked against the name
tls.sendall(b"GET " + path + b" HTTP/1.1\r\nHost: " + host.encode() + b"\r\n\r\n")

The name is still used for the Host header and for TLS, so websites and certificates work normally. (For plain http skip the TLS line.)

Problem 2: redirects.

Attack: a public URL replies 302 to an internal address, and the client follows it unchecked.
Fix: we never follow redirects. Any 3xx response is an error. In the code above this is automatic, because we send one request ourselves and read one response.
Why it works: a redirect only helps the attacker if our client obeys it. If we don't, the "go here instead" message is just text. If you must support redirects, run the full lookup, check and connect again for each hop.

Problem 3: IPv6.

Attack: a hostname with a harmless IPv4 record and an IPv6 record of ::1. The check saw only IPv4, the connection used IPv6.
Fix: getaddrinfo returns both IPv4 and IPv6, and we refuse if any of them is not public.
Why it works: every address we could possibly connect to has been checked, so there is no unchecked family left for the attacker to use.

Problem 4: two parsers read the URL differently.

Attack: a string like http://example.com\@evil.com where the checker sees one host and the HTTP library connects to another.
Fix: we parse the URL once, take the host, port and path from that single result, and use exactly those values to connect. No second library re-reads the original string. If the URL has odd parts such as backslashes or a user@ section, reject it.
Why it works: the host we check and the host we connect to now come from the same variable, so they can't disagree.

Problem 5: a bug in the app code still lets a request through. The four fixes above live in our code, and code can have bugs. So we add a second wall that doesn't depend on it.

Fix: network ACL deny rules for 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 on the fetcher's subnet (ACLs only filter traffic that crosses the subnet boundary), allow only outbound ports 80 and 443, and block the metadata address on the host: iptables -A OUTPUT -d 169.254.169.254 -j REJECT (AWS's own example limits it per user with -m owner --uid-owner; a plain rule like this one blocks every process on the host, which is fine for a fetcher with no role) (and fd00:ec2::254 with ip6tables if the IPv6 endpoint is on). Security groups can only allow, so they can't express "everything except private addresses". AWS also says neither security groups nor network ACLs filter metadata traffic, so the metadata address needs the host rule. An egress proxy such as Smokescreen is another way: the fetcher can only talk to the proxy, which does the lookup, check and connection itself.
Why it works: even if the fetcher is fooled into connecting to an internal address, the network drops the packet. The attacker has to beat the app and the network.

Problem 6: the credentials are there to be stolen.

Fix: run the fetcher as a separate service with no instance role. The service that writes to S3 never makes requests to user-chosen URLs.
Why it works: the metadata service only hands out credentials if the instance has a role. If the fetcher is tricked into asking for them, there is no role key to return.

Problem 7: the image itself is hostile.

Attack: a file that passes the JPEG header check but exploits the decoder, or a tiny file that expands to gigabytes.
Fix: decode in a separate process or container with no network, no credentials and CPU, memory and time limits. Read the width and height from the header first and refuse huge images. Re-encode the result and store only that.
Why it works: if the decoder is exploited, it is stuck in a box with nothing to steal and nowhere to connect. Re-encoding drops anything hidden in the original file.

Problem 8: a stolen key is still too powerful. Give the S3 writer one permission:

{ "Effect": "Allow",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::image-bucket/processed/*" }

Now a leaked key can write into one prefix. It can't read other buckets, list objects or call other services, so the damage is small even in the worst case.

Why all of them? Each one covers a failure of another. If the IP check has a bug, the network rule stops the connection. If the network rule is wrong, the fetcher has no role to steal. If a role is stolen anyway, it can only write to one prefix. No single control has to be perfect.

6. How to test it

Only test systems you own or are allowed to test.

Try direct private targets: 127.0.0.1, a 10.x address, 169.254.169.254, [::1], [fd00:ec2::254]. All should be rejected before any request is made.
Use a hostname you control that points to a private address. It should be rejected.
Test rebinding with a DNS server that answers public first, then private, with a tiny TTL. Check at the network level that no connection to the private address happens.
Try a host with only an IPv6 record.
Try a public URL that redirects to an internal address. It must not be followed.
Try odd URLs: backslashes, user@host, #, strange encodings.
Try other ports: 22, 6379, 8080.
From the fetcher host, curl a private address and the metadata address. They should fail even if the app has a bug.
Check the instance setting: aws ec2 describe-instances and look at MetadataOptions (HttpTokens, HttpPutResponseHopLimit, HttpEndpoint).
Send a huge file, a very slow response, a compressed bomb and an image with enormous dimensions.
Compare the error text and timing for every rejection. They should look the same.

7. If the release is in 30 minutes

Decide by how easy it is to exploit, how bad it is, and how much work the fix takes.

Before release:
- Switch to an allowlist of trusted image hosts, or turn off URL fetching and keep uploads. This is often a small change and the fastest safe option.
- If arbitrary URLs must stay, block internal and metadata addresses outside the app with a host firewall rule.
- Verify the claims: IMDSv2 is really required, redirects are really off, and the instance role is small.
Right after release: look up with getaddrinfo, check all addresses and connect to the checked one. Add size and time limits, generic errors and tests.
Later: a separate fetcher, isolated decoding, and monitoring and alerts.

My rule: don't ship arbitrary-URL fetching while its destination checks can still be bypassed. Ship with it off or on an allowlist, and add the full design afterwards. Odd URL spellings can wait, because the check runs on the resolved address. The connection problem can't.

8. Things that sound safe but aren't

"We only allow http and https." The metadata service and internal services are plain HTTP.
"We only accept JPEG and PNG." The check comes after the request, and it doesn't make decoding safe.
"We check the IP first." The client may look the name up again and connect somewhere else.
"We turned off redirects." That closes one path. Rebinding and IPv6 are still open.
"IMDSv2 is on." It blocks the plain-GET route to credentials, but not other internal services.
"We block 169.254.169.254." Text blocklists miss other spellings, the IPv6 address and hostnames that resolve to it.
"The security group blocks it." Security groups don't filter metadata service traffic.

Summary

The bug is that user input picks where the server connects. Fix that, not the symptoms.
Reaching the metadata address is not the same as stealing credentials. It depends on the IMDS version, what the attacker can see, and what the role can do.
IMDSv2 helps, but it doesn't fix SSRF.
Make sure the address you checked is the address you connect to.
Back up app checks with network rules. Prefer an allowlist or uploads.
Keep the fetcher isolated and the role small.