Server-Side Request Forgery (SSRF)

What Is SSRF?

SSRF is a vulnerability class that occurs when an application is fetching a remote resource without first validating the user-supplied URL.

Regular / In-Band SSRF:
- The attacker sees the response of the malicious request in the application.
Blind / Out-of-Band SSRF:
- The attacker does not directly see the response but observes effects or monitors interactions via external tools.

Depends on the functionality in the application that is being exploited
- Confidentiality – can be None / Partial (Low) / High
- Integrity – can be None / Partial (Low) / High
- Availability – can be None / Partial (Low) / High
Can lead to sensitive information disclosure, scan of internal network, compromise of internal services, remote code execution, etc.

Map the application
- Identify any request parameters that contain hostnames, IP addresses or full URLs
For each request parameter, modify its value to specify an alternative resource and observe how the application responds
- If a defense is in place, attempt to circumvent it using know techniques
For each request parameter, modify its value to a server on the internet that you control and monitor the server for incoming requests
- If no incoming connections are received, monitor the time taken for the application to respond

Review source code and identify all request parameters that accept URLs
- This could be done by combining both a black-box and white-box testing perspective
Determine what URL parser is being used and if it can be bypassed. Similarly determine what additional defenses are put in place that can be bypassed
Test any potential SSRF vulnerabilities

If the application allows for user-supplied arbitrary URLs, try the following attacks:
- Determine if a port number can be specified
- If successful, attempt to port-scan the internal network using Burp Intruder
- Attempt to connect to other services on the loopback address
If the application does not allow for arbitrary user-supplied URLs, try to bypass defenses using the following techniques:
- Use different encoding schemes
  - decimal-encoded version of 127.0.0.1 is 2130706433
  - 127.1 resolves to 127.0.0.1
  - Octal representation of 127.0.0.1 is 017700000001
- Register a domain name that resolves to internal IP address (DNS Rebinding)
- Use your own server that redirects to an internal IP address (HTTP Redirection)
- Exploit inconsistencies in URL parsing

If the application is vulnerable to blind SSRF, try to exploit the vulnerability using the following techniques:
Attempt to trigger an HTTP request to an external system you control and monitor the system for network interactions from the vulnerable server
Can be done using Burp Collaborator
If defenses are put in place, use the techniques mentioned in the previous slides to obfuscate the external malicious domain
Once you’ve proved that the application is vulnerable to blind SSRF, you need to determine what your end goal is
An example would be to probe for other vulnerabilities on the server itself or other backend systems

Defense in depth approach:

Sanitize and validate all client-supplied input data
Enforce the URL schema, port, and destination with a positive allow list
Do not send raw responses to clients
Disable HTTP redirections Note: Do not mitigate SSRF vulnerabilities using deny lists or regular expressions.

Segment remote resource access functionality in separate networks to reduce the impact of SSRF
Enforce “deny by default” firewall policies or network access control rules to block all but essential intranet traffic