Docs

Server Side Request Forgery (SSRF)

Suggest Edits
Severity: High
Test name: Server Side Request Forgery (SSRF)
Test ID: ssrf
Summary

Some web applications take the input URL parameter and retrieve the response content of a request. This allows an attacker to execute the Server Side Request Forgery (SSRF) attack by sending any request to any URL address through the victim application on the web server. It is possible if the application does not validate the URL parameter.

Blind Server Side Request Forgery vector:

The target application fails to validate user-controllable input used to construct server-side requests properly. An attacker can manipulate this input to trigger outbound requests to unauthorized resources without directly observing the responses, relying instead on side effects and indirect indicators. This can lead to unauthorized access to internal resources, and can be used to attack the server itself.

Impact

This vulnerability allows the attacker to:

  • Gain sensitive information on the server
  • Get access to internal services
  • Get access to Databases if the access is allowed for internal network
  • Scan host ports on internal networks
Example (PHP)

  1. Let’s imagine the following code is used on the server side for specific reasons ("image.php"):

    <?php
if (isset($_GET['url'])){
    $image = fopen($_GET['url'], 'rb');

 header("Content-Type: image/png");
    fpassthru($image);
}

  2. The following URL can be used to retrieve the web server statistics:

    https://www.{your_web_site}.com/image.php?url=http://localhost/server-status

  3. The following URL can be used to retrieve the passwd file content:

    https://www.{your_web_site}.com/image.php?url=file:///etc/passwd

  4. The following URL can be used to retrieve the meta-data of the cloud service:

    https://www.{your_web_site}.com/image.php?url=http://169.254.169.254/latest/meta-data/

    Note: 169.254.169.254 is a special IP address of the AWS EC2 instance metadata, that is used here as an example only.

Location

The issue can be found in the source code on the server side.

Remedy suggestions
  • Restrict supported protocols in your web application. Disable any unused schema, for example ftp://, dict://, file:///, gopher://.
  • Sanitize input by creating a list of trusted URLs (lists of hosts or a regex). Use the whitelist approach.
  • If a microservice architecture is used, then it is required to integrate a cross-service authentication mechanism (communication between all internal services should be authenticated).
  • AWS: IMDSv2 is an additional defense mechanism for AWS that mitigates some instances of SSRF if you are using a cloud environment. Migrate to IMDSv2 and disable old IMDSv1. Check out AWS documentation for more details.
Classifications
  • CWE-918
  • CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N
References

Updated 3 months ago