What is an SSRF attack?
When a web application fetches a remote resource without validating the URL provided by the user, an SSRF fault occurs. Even when secured by a firewall, VPN, or another sort of network access control list, it permits an attacker to force the program to send a forged request to an unexpected destination.
Fetching a URL has become a regular scenario as new online applications give end-users convenient functionalities. As a result, SSRF is becoming more common. Due to cloud services and the complexity of architectures, the severity of SSRF is also increasing.
How do SSRF attack works?
When a visitor makes a request to a web server or clicks on a hyperlink, they are sent files in the public HTML or www folders that are meant to be seen by the entire world. Private folders and databases are often only accessible to highly privileged users, such as server administrators.
Unauthorized activities or access to data within the business can often arise from a successful SSRF attack, either in the vulnerable application itself or on other back-end systems with which the program can interface. The SSRF vulnerability could allow an attacker to execute arbitrary commands in some circumstances.
Types of SSRF attacks
- Blind SSRF: In a Blind SSRF, the attacker is unable to control the data of packets sent to a trusted internal network application. The attacker has complete control over the server’s IP address and ports. 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 title of the page 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.
How to prevent the attacks?
SSRF can be avoided by employing some or all the defense in-depth controls listed below:
From Layer of the Network:
- To decrease the impact of SSRF, segment remote resource access capabilities into different networks at the network layer.
- To prevent all except critical intranet traffic, use “deny by default” firewall settings or network access control rules.
- Establish a lifetime and ownership for security system rules depending on apps.
- Firewalls should keep track of all permitted and banned network flows.
From Layer of the Application:
- All client-supplied input data should be sanitized and validated.
- With a positive allow list, enforce the URL schema, port, and destination.
- Clients should not receive raw answers.
- HTTP redirections should be disabled.
We now understand how the SSRF attack works and the potential repercussions. Obtaining illegal access to an organization’s data can lead to a variety of consequences. To assist you in overcoming this, some ways to safeguard your Network Infrastructure are listed above. If you want to secure your network infrastructure, cloud solutions, or data center services, contact us at +91-9773973971. If you want to read more about ethical hacking and OWASP top vulnerabilities, you can go to my blogs.