Server-Side Request Forgery (SSRF) involves an attacker tricking a server into making unauthorized requests on behalf of the attacker. This type of attack can be hazardous, as it can allow the attacker to gain access to sensitive information, such as user data or internal network details.
In this blog post, we will explain what SSRF is, what’s the impact of it and how it works and basic to prevent it.
SSRF (Server Side Request Forgery)
What is SSRF?
Server-side request forgery, or SSRF, is a type of web security attack in which an attacker manipulates a server to perform actions on their behalf. This is often done by tricking the server into making requests to internal resources that are not intended to be accessible from the outside, such as databases or network services.
For example, suppose a server is configured to fetch data from a website using a user-supplied URL. An attacker could craft a special URL that, when loaded by the server, causes the server to request an internal system on the network, such as a database server. If the server is not properly configured, the attacker may be able to access sensitive information or manipulate the database. This attack is particularly dangerous because it allows the attacker to access internal systems that are typically not directly accessible from the internet.
Best live example- Paige Thompson is accused of breaking into a Capital One server and gaining access to 140,000 Social Security numbers, 1 million Canadian Social Insurance numbers, and 80,000 bank account numbers. https://application.security/free-application-security-training/server-side-request-forgery-in-capital-one
Types of SSRF
There are several types of SSRF attacks, depending on the specific tactics used by the attacker and the vulnerabilities exploited in the target server. Some common types of SSRF attacks include:
Blind SSRF
Blind SSRF attacks occur when the host server does not return visible data to the attackers. We must supply a URL followed by a colon and a port number to attack this sort of SSRF; we can determine the open and closed ports of the server by analyzing responses and error messages from the server. To verify the status of the various ports, we used this approach.
Partial Response SSRF
We get a restricted response from the server with this form of SSRF, such as the page title or access to resources, but we can’t see the data. This type of vulnerability can be leveraged to read local system files such as /etc/config, /etc/hosts, /etc/passwd, and many others by controlling only certain parts of the packet that arrive internal program. We can read files on the system using the file:/ protocol. In some circumstances, XXE injection and DDoS vulnerabilities like these can be used to exploit partial SSRF vulnerabilities.
Full Response SSRF
We have complete control over the Packet in Full SSRF. Now we may access the internal network’s services and look for vulnerabilities. We can use protocols like file:/, dict:/, HTTP://, gopher:/, and so on with this form of SSRF. We have a lot of freedom here to make different requests and abuse the internal network if there are any weaknesses. By submitting huge strings in the request, the whole SSRF vulnerability might cause the application to crash due to buffer overflow.
SSRF IMPACTS:
By this attack, an attacker can gather information about local ports, IP addresses, Remote Code Execution (RCE), and can also discover the IP addresses of servers running behind a reverse proxy, etc.
let’s make a simple php page to know more about SSRF:-
Let’s look for example at the following functionality, which allows a user to change its profile picture:
SSRF.PHP:
<?php
if (isset($_GET['url'])){
#Get the new picture
$url= $_GET['url'];
$content=file_get_contents($url);
header("Content-Type: image/png");
echo $content;
#user_change_picture($content)
#Redirect to OK
header("HTTP/1.1 301 Moved Permanently");
header("Location:/web/ok.php");
}else{
echo "Set an URL to change your picture";
}We notice two things: first, that url parameter is not sanitized before it is used in file_get_contents($url), and on the other, content is written (echo $content;) while a redirection occurs.
This functionality is therefore vulnerable to SSRF. Here are some possible explorations:
- Access to an apache functionality of the server (unexposed):
http://test.com/ssrf.php?url=http://localhost/server-status - Access to a local web service of the server (unexposed):
http://test.com/ssrf.php?url=http://localhost:8080 - Access to a file of the server (LFI: Local File Inclusion):
http://test.com/ssrf.php?url=file:///etc/passwd - Enumerate local running service: http://test.com/ssrf.php?url=http://localhost:8000
Likewise, you can knock every port like that to know internal running service.
SSRF attacks can be used for a variety of purposes, including:
- Accessing internal systems and networks that are not normally accessible from the internet
- Enumerating internal network resources and services
- Bypassing network firewalls and access controls
- Launching distributed denial of service (DDoS) attacks by using the vulnerable web application as a reflector
- Exfiltrating sensitive data from internal systems
Preventing SSRF attacks requires a multi-faceted approach that includes the following measures:
Implement strict access controls:
Only allow authorized users to access sensitive resources, and limit the types of requests that can be made to those resources.
Validate user input: Verify that any user-provided input, such as URLs or IP addresses, is valid and safe before processing it.
Use a web application firewall (WAF): A WAF can help to detect and block malicious requests, such as those used in SSRF attacks.
Monitor network traffic: Regularly monitor network traffic for suspicious activity, such as unauthorized access to sensitive resources.
By implementing these measures, organizations can help to protect themselves from SSRF attacks and keep their sensitive information secure.
To prevent SSRF vulnerabilities, it is important to ensure that web applications properly validate and sanitize user-supplied input, especially when generating requests to external servers. It is also important to follow best practices for securing internal networks and systems, such as properly configuring firewalls and access controls.
Must Visit there is a crazy GitHub repository of payloads for web penetration testing and security assessments:
https://github.com/InfoSecWarrior/Offensive-Payloads.git
Thank You for reading this blog.
If you have any doubt and suggestion regarding this then feel free to contact with me.
You can contact me on twitter:-
