Server-Side Request Forgery (SSRF) is a web application security vulnerability that allows the attacker to force the server to make unauthorised requests to any local or external source on behalf of the web server. It allows an attacker to interact with internal systems, potentially leading to data leaks, service disruption, or even remote code execution.
Unlike traditional attacks, SSRF targets how a server communicates with internal or external resources. If left unpatched, it can result in major security breaches like the Capital One AWS hack.
In this guide, we’ll explore:
✅ How SSRF attacks work
✅ Types: Blind, Semi-Blind, and Non-Blind SSRF
✅ Real-world exploitation cases
✅ Best practices for preventing SSRF attacks
🎯 Want to practice SSRF attacks in a lab environment? Try:
How SSRF Works
SSRF occurs when a web application fetches resources from a user-supplied URL without proper validation. Attackers exploit this flaw to send requests to internal services, retrieve sensitive data, or interact with cloud metadata APIs.
Step-by-Step Attack Process:
1️⃣ User Input is Accepted → The app allows users to enter URLs.
2️⃣ Server Fetches the URL → No restrictions are applied.
3️⃣ Attacker Injects Malicious Requests → Instead of a valid URL, they input an internal service endpoint.
4️⃣ Internal Resources are Accessed → The server unknowingly leaks sensitive data.
✅ Example of a vulnerable request:
GET /fetch?url=http://localhost/admin
If unrestricted, this can expose internal admin pages, APIs, or cloud metadata endpoints.
Types of SSRF Attacks
1. Non-Blind SSRF (Direct Response SSRF)
In this case, the attacker receives an immediate response, making it easy to extract data.
🔹 Possible Impact:
- Reading private API responses
- Extracting server logs or credentials
- Accessing internal dashboards
✅ Example:
GET /fetch?url=http://192.168.1.1/admin
If the server discloses internal admin data, the attacker gains access.
2. Blind SSRF (Out-of-Band SSRF – OOB)
Blind SSRF doesn’t return a response to the attacker. Instead, they monitor external services to confirm that a request was made.
🔹 How it works:
- The attacker forces the server to ping an external controlled domain.
- If the external server logs the request, SSRF is confirmed.
✅ Example:
GET /fetch?url=http://attacker.com/log
The attacker checks logs on attacker.com to verify execution.
3. Semi-Blind SSRF (Time-Based SSRF)
This method infers whether a service exists based on response time delays.
🔹 Attack Strategy:
- The attacker requests a real service (slow response confirms existence).
- The attacker requests a non-existent service (fast failure confirms non-existence).
✅ Example:
GET /fetch?url=http://192.168.1.1:22
If the server takes longer to respond, it means Port 22 (SSH) is open.
Real-World Exploitation Cases
🔴 1. Capital One AWS Breach (2019)
- An SSRF vulnerability leaked AWS metadata service credentials.
- The attacker stole 100M+ banking records.
- 🔗 Read More
🔴 2. Uber’s Bug Bounty Report
- SSRF allowed access to internal Uber APIs.
- Researchers exploited invoice processing systems.
- 🔗 HackerOne Report
How to Prevent SSRF Attacks
✅ 1. Restrict External Requests
- Use an allowlist of trusted domains.
- Block access to internal IP ranges (e.g.,
127.0.0.1,169.254.169.254).
✅ 2. Validate & Sanitize User Input
- Reject file://, gopher://, ftp://, and dict:// requests.
- Enforce strict URL validation using regex.
✅ 3. Enforce Network Segmentation
- Separate external and internal systems to prevent cross-network requests.
- Deploy firewalls to filter outbound connections.
✅ 4. Disable Cloud Metadata Access
- Block access to AWS, GCP, and Azure metadata endpoints:
http://169.254.169.254/latest/meta-data/
✅ 5. Monitor & Log Requests
- Track outbound connections and set alerts for suspicious requests.
- Use Web Application Firewalls (WAFs) for real-time request filtering.
Conclusion
SSRF remains a high-risk security flaw, allowing attackers to steal data, bypass firewalls, and exploit cloud services. Whether it’s direct response SSRF, blind SSRF, or time-based SSRF, organizations must enforce proper security measures to mitigate these threats.
To defend against SSRF:
✅ Restrict external requests
✅ Validate user input properly
✅ Implement network segmentation
✅ Monitor server logs for anomalies
🎯 Want hands-on practice? Check out:
🚀 Stay secure! Always validate, monitor, and restrict external requests.
FAQs
1. Why is SSRF so dangerous?
SSRF allows attackers to bypass firewalls, read internal services, and steal sensitive data, sometimes leading to remote code execution.
2. What’s the difference between Blind SSRF and Non-Blind SSRF?
- Non-Blind SSRF returns an immediate response with data.
- Blind SSRF doesn’t return a response, but attackers can confirm it through external logging.
3. Can firewalls prevent SSRF?
Firewalls help, but input validation and proper network segmentation are the best defenses.
4. How do I test if my website is vulnerable?
Use Burp Suite, TryHackMe labs, or PortSwigger’s SSRF challenges to detect vulnerabilities.
5. What is the best way to prevent SSRF?
✅ Use URL allowlists, block internal requests, validate inputs, and monitor outgoing traffic.
🔹 Please don’t forget to leave a review.
Want to read about broken access control!!!!!
