Server-Side Request Forgery (SSRF)

Server-Side Request Forgery (SSRF) – Complete Guide for GIAC GCIH

Server-Side Request Forgery (SSRF)

Why is SSRF Important?
Server-Side Request Forgery (SSRF) is one of the most critical web application vulnerabilities in modern environments. It was added to the OWASP Top 10 (2021) as its own category (A10), reflecting its growing prevalence and impact. SSRF is particularly dangerous because it allows an attacker to leverage a trusted server to make requests on their behalf, effectively bypassing firewalls, access controls, and network segmentation. In cloud environments (AWS, Azure, GCP), SSRF has been used in high-profile breaches to access internal metadata services, steal credentials, and pivot deeper into infrastructure. For the GIAC GCIH (GIAC Certified Incident Handler) exam, understanding SSRF is essential because it falls squarely within the realm of web application attacks that incident handlers must detect, analyze, and respond to.

What is SSRF?
Server-Side Request Forgery (SSRF) is a vulnerability in which an attacker can induce a server-side application to make HTTP requests (or other protocol requests) to an arbitrary destination chosen by the attacker. The key distinction from other request-based attacks is that the server itself is making the request, not the client's browser.

In a typical SSRF scenario:
- A web application accepts a URL or network address as user input (or as part of a parameter).
- The server fetches the resource at that URL on behalf of the user.
- The attacker manipulates this input to target internal systems, cloud metadata endpoints, or other resources that should not be publicly accessible.

There are two main types of SSRF:

1. Basic (In-Band) SSRF: The attacker can see the response from the forged request directly in the application's output. For example, a web app that fetches a URL and displays its contents could be tricked into displaying internal resources.

2. Blind (Out-of-Band) SSRF: The attacker cannot see the response directly but can infer results through timing, error messages, DNS lookups, or by directing responses to an attacker-controlled server. This is more subtle but still dangerous.

How Does SSRF Work?

Consider a web application with a feature that allows users to provide a URL to fetch a preview of an image or webpage. The server-side code might look like this (pseudocode):

url = getUserInput("url")
response = httpClient.get(url)
return response.body

An attacker can exploit this by providing malicious URLs:

Attack Scenario 1 – Accessing Internal Services:
Instead of providing a legitimate external URL, the attacker submits:
http://192.168.1.10:8080/admin
The server, which is on the internal network, makes the request to this internal IP address, potentially accessing an admin panel that is not exposed to the internet.

Attack Scenario 2 – Cloud Metadata Theft (Critical in Cloud Environments):
The attacker submits:
http://169.254.169.254/latest/meta-data/iam/security-credentials/
This is the AWS EC2 metadata endpoint. If the application is running on AWS, the server will fetch IAM credentials, access keys, and tokens, which the attacker can then use to compromise the entire AWS account. This was the technique used in the Capital One breach (2019).

Attack Scenario 3 – Port Scanning Internal Networks:
The attacker can iterate through internal IP addresses and ports to map internal infrastructure:
http://10.0.0.1:22 (SSH), http://10.0.0.1:3306 (MySQL), etc.
Different responses or timing differences reveal which services are running.

Attack Scenario 4 – Protocol Smuggling:
Some SSRF implementations support protocols beyond HTTP, such as:
- file:///etc/passwd – Reading local files
- gopher:// – Crafting arbitrary TCP packets to interact with internal services like Redis, Memcached, or SMTP
- dict:// – Interacting with dictionary services

Common SSRF Bypass Techniques:
Developers often try to block SSRF with denylists, but attackers can bypass them using:
- IP address encoding: Using decimal (2130706433), hex (0x7f000001), or octal (0177.0.0.1) representations of 127.0.0.1
- DNS rebinding: Setting up a domain that initially resolves to an allowed IP, then changes to an internal IP
- URL redirection: Pointing to an attacker-controlled server that redirects to an internal address
- Alternative localhost references: Using 0.0.0.0, [::1], localhost, or 127.0.0.1 variations
- URL parsing inconsistencies: Using @ symbols, URL-encoded characters, or fragments to confuse validation logic

Impact of SSRF:
- Access to internal services and APIs not meant to be publicly exposed
- Credential theft from cloud metadata services (AWS, GCP, Azure)
- Reading sensitive files from the server
- Remote code execution (when combined with other vulnerabilities)
- Internal network reconnaissance and port scanning
- Pivoting to attack other internal systems
- Denial of service against internal or external systems

SSRF Defenses and Mitigations:
- Input validation with allowlists: Only permit requests to known, trusted URLs/domains rather than trying to block malicious ones (denylists are easily bypassed)
- Network segmentation: Restrict outbound network access from web servers using firewalls and security groups
- Disable unnecessary URL schemes: Only allow HTTP/HTTPS; block file://, gopher://, dict://, etc.
- Block access to metadata endpoints: Use IMDSv2 (Instance Metadata Service v2) on AWS, which requires a token-based approach, or block 169.254.169.254 at the network level
- Use a dedicated HTTP client: That does not follow redirects or supports only specific protocols
- Implement response handling carefully: Do not return raw responses from fetched URLs to users
- Monitor and log: Watch for unusual outbound requests from servers, especially to internal IP ranges or metadata endpoints

Detection of SSRF Attacks:
- Monitor web application logs for requests containing internal IP addresses (10.x.x.x, 172.16.x.x–172.31.x.x, 192.168.x.x, 127.0.0.1, 169.254.169.254)
- Watch for unusual DNS queries from the web server
- Analyze outbound traffic from web servers for connections to internal networks
- Use Web Application Firewalls (WAFs) with SSRF-specific rules
- Monitor cloud metadata service access logs (e.g., AWS CloudTrail for IMDS access)

---

Exam Tips: Answering Questions on Server-Side Request Forgery (SSRF)

1. Know the definition cold: SSRF occurs when an attacker can make the server send requests to unintended locations. The keyword is that the server makes the request, not the client. This differentiates SSRF from Client-Side Request Forgery (CSRF).

2. Don't confuse SSRF with CSRF: This is a common exam trap. CSRF (Cross-Site Request Forgery) tricks a user's browser into making unintended requests. SSRF tricks the server into making unintended requests. If a question mentions the server fetching a URL provided by the user, think SSRF.

3. Remember the cloud metadata angle: If a question mentions AWS, cloud environments, or the IP address 169.254.169.254, SSRF is almost certainly the answer. Know that this IP is the cloud instance metadata service and is a prime SSRF target.

4. Recognize common SSRF indicators in scenarios: Look for application features that fetch URLs on behalf of users: URL preview/thumbnail generators, PDF generators, file import from URL, webhook configurations, and image fetchers.

5. Know the key defense: If asked about the best mitigation, allowlisting (only allowing requests to specific, known-good destinations) is generally the strongest defense. Denylisting (blocking known-bad IPs) is weak because of the many bypass techniques.

6. Understand IMDSv2: AWS Instance Metadata Service v2 (IMDSv2) requires a PUT request with a special header to obtain a session token before accessing metadata. This mitigates basic SSRF attacks because most SSRF vectors only allow simple GET requests.

7. Protocol awareness: If a question mentions file://, gopher://, or dict:// protocol schemes in a URL parameter, think SSRF. These are commonly used in SSRF to read local files or interact with internal services.

8. Look for network-level indicators: Questions about incident detection may reference unexpected outbound connections from a web server to internal IP ranges, RFC 1918 addresses in URL parameters, or connections to 127.0.0.1 from the application layer.

9. Capital One breach reference: The 2019 Capital One breach is the most cited real-world example of SSRF. An attacker exploited an SSRF vulnerability in a WAF to access AWS metadata credentials. If this breach is referenced, SSRF is the relevant attack vector.

10. Response-based vs. blind: If a question describes an attacker seeing the content of an internal page returned in the response, that is basic/in-band SSRF. If the attacker cannot see the response but uses timing or out-of-band techniques (DNS, HTTP callbacks to an attacker server), that is blind SSRF.

11. Answering strategy: When you see an exam question about a web app that takes a URL as input and the attacker changes it to target an internal resource, immediately identify it as SSRF. Focus on: (a) what was the target (internal service, cloud metadata, local file), (b) what is the appropriate mitigation (allowlisting, network controls, IMDSv2), and (c) what differentiates it from other attacks (server makes the request, not the browser).