#SecurityExplained S-90: CWE Top 25: CWE-918: Server-Side Request Forgery (SSRF)
The web server receives a URL or similar request from an upstream component and obtains its contents, but it does not check that the request is routed to the correct destination.
1/n
The web server receives a URL or similar request from an upstream component and obtains its contents, but it does not check that the request is routed to the correct destination.
1/n
2/n
Malicious parties can use CWE-918, also known as server-side request forgeries (SSRF), to trick a server into making requests to obtain access to internal infrastructure, sensitive data, and more.
Malicious parties can use CWE-918, also known as server-side request forgeries (SSRF), to trick a server into making requests to obtain access to internal infrastructure, sensitive data, and more.
3/n
The use of URLs helps identify the attack surface for SSRF. Although sanitization and allow lists are two more effective techniques available, they can be challenging to manage.
The use of URLs helps identify the attack surface for SSRF. Although sanitization and allow lists are two more effective techniques available, they can be challenging to manage.
4/n
Server-Side Request Forgery (SSRF) is an attack in which an attacker uses a web application's ability to make unauthorized requests to internal or external services.
Server-Side Request Forgery (SSRF) is an attack in which an attacker uses a web application's ability to make unauthorized requests to internal or external services.
5/n
For example, if the program contains functionality that sends requests to other servers and the attacker can tamper with it, your web server can be turned into a proxy.
For example, if the program contains functionality that sends requests to other servers and the attacker can tamper with it, your web server can be turned into a proxy.
6/n
As a result, an attacker can reach systems that are otherwise behind a firewall or access private resources on the local host itself, depending on the web server's settings.
As a result, an attacker can reach systems that are otherwise behind a firewall or access private resources on the local host itself, depending on the web server's settings.
7/n
A malicious attacker can use this vulnerability to force a server-side application to send HTTP requests to a domain of their choosing.
A malicious attacker can use this vulnerability to force a server-side application to send HTTP requests to a domain of their choosing.
8/n
# Impact:
A typical example is information disclosure via a port scan of internal hosts and returned service banners enumerated. In certain circumstances, a detailed error message will be sent to indicate the port's status; in others, a time-based approach will be required.
# Impact:
A typical example is information disclosure via a port scan of internal hosts and returned service banners enumerated. In certain circumstances, a detailed error message will be sent to indicate the port's status; in others, a time-based approach will be required.
9/n
If a hosting provider hosts the application, it is possible to reveal instance metadata, such as public SSH keys, credentials, and private IP address blocks.
If a hosting provider hosts the application, it is possible to reveal instance metadata, such as public SSH keys, credentials, and private IP address blocks.
10/n
In rare situations, the vulnerability can be leveraged to access the contents of local files on the webserver. This is accomplished by employing a different handler: 'file:/'.
In rare situations, the vulnerability can be leveraged to access the contents of local files on the webserver. This is accomplished by employing a different handler: 'file:/'.
11/n
An attacker may be able to view web application source code, configuration files, and other sensitive data due to this.
An attacker may be able to view web application source code, configuration files, and other sensitive data due to this.
12/n
# Mitigations:
Keep an allowlist of DNS or IP addresses that the web application is allowed to visit.
If a denylist is required, ensure that all user input is thoroughly validated and that no private IP addresses are allowed.
# Mitigations:
Keep an allowlist of DNS or IP addresses that the web application is allowed to visit.
If a denylist is required, ensure that all user input is thoroughly validated and that no private IP addresses are allowed.
13/n
Avoid delivering raw responses from the server-side to the client-side by sanitizing all user input used in URLs and other requests.
To restrict all superfluous traffic, use firewall policies or network access control rules.
Avoid delivering raw responses from the server-side to the client-side by sanitizing all user input used in URLs and other requests.
To restrict all superfluous traffic, use firewall policies or network access control rules.
n/n
Assure that only HTTP(S) protocols can be used, and if different handlers are required, ensure that a robust allowlist is employed. It's also essential to avoid HTTP redirection.
Assure that only HTTP(S) protocols can be used, and if different handlers are required, ensure that a robust allowlist is employed. It's also essential to avoid HTTP redirection.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
