- CWE-22: Path Traversal
- CWE-78: OS Command Injection
- CWE-79: Cross-Site Scripting
- CWE-89: SQL Injection
- CWE-90: LDAP Injection
- CWE-91: XML Injection
- CWE-94: Code Injection
- CWE-98: PHP File Inclusion
- CWE-113: HTTP Response Splitting
- CWE-119: Buffer Errors
- CWE-130: Improper Handling of Length Parameter Inconsistency
- CWE-193: Off-by-one Error
- CWE-200: Information Exposure
- CWE-211: Information Exposure Through Externally-Generated Error Message
- CWE-236: Improper Handling of Undefined Parameters
- CWE-276: Incorrect Default Permissions
- CWE-284: Improper Access Control
- CWE-285: Improper Authorization
- CWE-287: Improper Authentication
- CWE-297: Improper Validation of Certificate with Host Mismatch
- CWE-306: Missing Authentication for Critical Function
- CWE-312: Cleartext Storage of Sensitive Information
- CWE-345: Insufficient Verification of Data Authenticity
- CWE-352: Cross-Site Request Forgery
- CWE-384: Session Fixation
- CWE-427: Uncontrolled Search Path Element
- CWE-434: Unrestricted Upload of File with Dangerous Type
- CWE-476: NULL Pointer Dereference
- CWE-521: Weak Password Requirements
- CWE-601: Open Redirect
- CWE-611: Improper Restriction of XML External Entity Reference ('XXE')
- CWE-613: Insufficient Session Expiration
- CWE-618: Exposed Unsafe ActiveX Method
- CWE-671: Lack of Administrator Control over Security
- CWE-798: Use of Hard-coded Credentials
- CWE-799: Improper Control of Interaction Frequency
- CWE-822: Untrusted Pointer Dereference
- CWE-835: Infinite Loop
- CWE-918: Server-Side Request Forgery (SSRF)
- CWE-942: Overly Permissive Cross-domain Whitelist
CWE is a trademark of the MITRE Corporation.
Server-Side Request Forgery [CWE-918]
This weakness describes a case where the attacker can leverage the ability of a web application to perform unauthorized requests to internal or external systems.
Created: November 12, 2018
Latest Update: November 16, 2018
Table of Content
- Potential impact
- Affected software
- Exploitation Examples
- Severity and CVSS Scoring
Server-side request forgery or SSRF leverages the ability of a web application to perform unauthorized requests to internal or external systems. If the web application contains functionality that sends requests to other servers and the attacker can interfere with it, it is possible to turn your web server into a proxy. Depending on the configuration of the web server, an attacker can reach systems that are otherwise behind a firewall, or access private resources on the localhost itself.
2. Potential impact
The severity can vary from low to critical, depending on what the affected functionality can reach, either internally or externally.
Internal Service Interaction:
This is due to the vulnerable web application being used to interact with certain internal services, which in certain cases do not require authentication. Such examples are MongoDB and Redis. The impact can vary from minor information disclosure to database access, and even to remote code execution.
Information disclosure via a port scan of internal hosts and enumeration of returned service banners is a common example. In some cases verbose error message will be returned to indicate the status of the port, in other cases a time-based approach must be used.
If the web application is being hosted via a hosting provider, it is possible to disclose its instance metadata, such as public SSH keys, credentials, and private IP address blocks.
Local File Disclosure:
The vulnerability can also be used in some cases to read contents of local files on the web server. This is achieved by using an alternate handler: 'file://'. This can also lead to web application source code, configuration files, and various other sensitive files being read by an attacker.
SSRF can be used in conjunction with HTTP redirects to redirect a victim to a malicious web page. This can be used to serve malware, to harvesting credentials.
3. Affected software
Any code residing on the web server that an attacker can manipulate to insert arbitrary locations. This includes base web application functionality or third-party components.
4. Exploitation Examples
A typical exploitation scenario for web applications hosted on hosting provider platforms such as Amazon EC2 and Digital Ocean is to request the instance metadata service of each provider, which returns information about the hosted instance, such as the private IP subnet, OpenSSH public keys, and account details.
An example request is as follows, the 'url' HTTP GET parameter is part of a vulnerable script that queries a remote URL and returns its contents to the page, in this case it will return the Amazon EC2 instance's public OpenSSH key:
GET /search.php/?url=http://[host]/latest/meta-data/public-keys/0/openssh-key HTTP/1.1
Another common example is for the vulnerable application to be used to read local files that the web server has the relevant access rights to. Examples could be database credentials, web application source code, SSH keys, or configuration files.
The format of the following example request is the same as above. In this case it will return the '/etc/passwd' UNIX file, revealing the users of the underlying system. Note that the 'file://' handler is used instead of 'https://', this references local files:
GET /search.php/?url=file:///etc/passwd HTTP/1.1
An example of vulnerable PHP code is shown below:
$req = curl_init();
curl_setopt($req, CURLOPT_URL, $_POST["handler"]);
curl_setopt($req, CURLOPT_RETURNTRANSFER, 1);
$output = curl_exec($req);
$url = $_GET['url'];
$grab = fopen($url, 'rb');
An example of vulnerable Ruby code is shown below:
An example of vulnerable Java code is shown below:
InetAddress inetAddress = InetAddress.getByName(url.getHost());
HttpURLConnection req = (HttpURLConnection)(url.openConnection());
5. Severity and CVSS Scoring
The nature of what can be determined and accessed via the SSRF vulnerability will dictate the overall CVSS score. A few examples are shown below:
If a level of privilege is required to exploit the vulnerability, and the SSRF vulnerability can be used to access the cloud host instance metadata and return credentials which can be used to access the instance, it should be scored as follows:
8.8 [CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H] – High severity.
If no privilege is required, and the SSRF vulnerability can be used to determine open ports on the web server hosting the web application and other internal subnets, it should be scored as follows: 5.3 [CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N] – Medium severity.
If no privilege is required, and the SSRF vulnerability can be used to read local files from the web server (in this example, files that reveal sensitive information), it should be scored as follows:
7.5 [CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N] – High Severity
Maintain a whitelist of allowed DNS or IP addresses that the web application can access. If a blacklist is necessary, ensure that thorough validation is performed on user input, and that private IP addresses are not permitted. Ensure that only the HTTP(S) protocols can be used, and as before if it necessary to use alternate handlers, make sure robust whitelist is used. It is also necessary to prevent HTTP redirects.
Common Fix Errors and Bypasses:
It is dangerous to rely on a blacklist to filter user input, there are numerous techniques an attacker can use for various exploitation cases. A few basic examples are listed below:
IP Address Encoding:
Alternate IP addresses encodings can fool weak blacklists:
If certain domain names are blacklisted, HTTP redirects can be used to bypass this restriction:
http://companyx.app.localhost.127.0.0.1.nip.io - will use the ‘nip.io’ DNS service and resolve to localhost.
URL Scheme Manipulation:
Copyright Disclaimer: Any above-mentioned content can be copied and used for non-commercial purposes only if proper credit to High-Tech Bridge is given.↑ Back to Top