Server-Side Request Forgery (SSRF)

Download as pdf or txt
Download as pdf or txt
You are on page 1of 5

Server-side Request Forgery (SSRF)

SSRF (Server-Side Request Forgery) vulnerability is a type of security vulnerability that


allows attackers to send crafted requests from a vulnerable web application to other
internal or external resources on behalf of the application.

To understand SSRF vulnerability better, imagine you have a web application that
allows users to input a URL to fetch the contents of that URL. The web application then
fetches the contents of the URL and displays them to the user. However, if the
application does not properly validate the input URL, an attacker could craft a
malicious URL that points to an internal resource, such as a database server, that
should not be accessible to the public.

The attacker could then send a request to the vulnerable web application with the
malicious URL as the input, and the web application would unknowingly fetch the
contents of the internal resource and return them to the attacker. This can lead to
sensitive information disclosure, unauthorized access to internal resources, and even
remote code execution on the vulnerable system.
Another example would be, let's say there's a web application that allows users to
fetch the latest news from a given URL. The web application sends a GET request to
the URL provided by the user, retrieves the news content, and displays it on the
webpage. Now, an attacker could provide a URL like "http://localhost/admin" to the
application.

If the application is vulnerable to SSRF, it will send a request to the internal resource
"http://localhost/admin" from the server side, and the attacker can access the
sensitive admin panel data without authorization.

Types of SSRF Attacks

1. Non-Blind/Basic SSRF:

Non-blind/basic SSRF attacks occur when the attacker receives a direct response
from the target system, allowing them to see the response body. In this type of attack,
the attacker can send a request to the target system and receive a response that
contains sensitive information.

Example: An attacker discovers an SSRF vulnerability on a web application that allows


users to upload images. The attacker uses this vulnerability to send a request to an internal
server that is running a database service. The server responds with a database dump that
contains sensitive information such as usernames and passwords. Since the attacker can see
the response body, they can easily extract this information and use it to gain unauthorized
access to the target system.

2. Semi-Blind SSRF:

Semi-blind SSRF attacks occur when the attacker receives an indirect response from
the target system, but cannot directly see the response. In this type of attack, the
attacker can send a request to the target system and receive an HTTP response code,
but not the actual response body.
Example: Consider a web application that allows users to download files by specifying a
URL. An attacker discovers an SSRF vulnerability on this website and tries to download a
file from an internal server by specifying the URL http://192.168.1.10/secret/file.txt. The
target application will forward the request to the internal server and receive an HTTP
response code indicating success or failure. However, since the attacker cannot directly see
the response body, they will need to use other methods to determine whether the request
was successful, such as the timing or size of the response code.

3. Blind SSRF:

Blind SSRF attacks occur when the attacker does not receive any response from the
target system, but can still use the vulnerability to probe for internal systems. In this
type of attack, the attacker sends a request to a specified URL or IP address and waits
for a response from the application. However, since the response is not returned to
the attacker, the attacker must use other techniques to determine whether the request
was successful.

Example: Let's say an attacker discovers an SSRF vulnerability on a website and tries to
access a restricted server on the internal network by sending a request to
http://192.168.1.10. If the target application is vulnerable, it will forward the request to the
internal server. However, since the attacker will not receive any response from the server,
they will need to use other methods, such as timing or side-channel attacks, to determine
whether the request was successful.

Impact of SSRF Attacks


 The main impact of SSRF is the ability of attackers to access sensitive
information and execute unauthorized actions on behalf of the vulnerable
server.
 It can lead to data leakages, such as the disclosure of internal network addresses,
credentials, and other confidential information.
 It can also allow attackers to perform actions like port scanning, firewall bypass,
and even compromise other systems on the network.
 The consequences of SSRF can be severe, such as loss of sensitive information,
disruption of business operations, and reputational damage.
 In some cases, SSRF attacks can result in the complete compromise of an
organization’s network, allowing attackers to gain access to critical systems and
sensitive data.

Mitigations

Here are five ways to mitigate SSRF attacks:

 Whitelist the hostnames or IP addresses that your application needs to access.


 Ensure that the response received is in the expected format and do not send the
raw response body to the client.
 Disable unused URL schemas to prevent attackers from using potentially
dangerous schemas.
 Enable authentication on internal services to prevent unauthorized access.
 Validate all user inputs, implement network segmentation, conduct regular code
reviews, and monitor log files for suspicious activity.
REFERENCE
https://owasp.org/www-community/attacks/Server_Side_Request_Forgery

https://www.imperva.com/learn/application-security/server-side-request-forgery-
ssrf/

https://www.geeksforgeeks.org/server-side-request-forgery-ssrf-in-depth/

https://blog.intigriti.com/hackademy/server-side-request-forgery-ssrf/

https://infosecwriteups.com/ssrf-server-side-request-forgery-2865e87efc3

https://www.acunetix.com/blog/articles/server-side-request-forgery-vulnerability/

https://www.invicti.com/learn/server-side-request-forgery-ssrf/

You might also like