Server-side request forgery (SSRF) is a scenario in which the attacker can coerce the vulnerable server to make requests to other hosts on the attacker’s behalf. For instance, the server implements an API that translates to the server forwarding the request to a different microservice. The attacker is able to provide arbitrary input for the forwarded request, allowing the attacker access to data they otherwise wouldn’t be able to acquire. The server is behaving as a proxy between the attacker and services the server has authorization to access.
Interacting with backend services
Without prior knowledge of the network topography for a distributed system, attackers will have a tough time using SSRF to proxy requests through a vulnerable web server. There are some known targets of interest for cloud-oriented architectures, however. For instance, Amazon Web Services (AWS) provides virtual machines with the ability to query against a metadata service at 169.254.169.254, and the same goes for virtual machines in other cloud providers like Azure. More on this below:
Testing multiple protocols
With an SSRF vulnerability, it’s worth attempting to try different protocols for web requests to backend targets, e.g.:
curl file:///etc/passwdExecuted on a host vulnerable to SSRF, if the web application reveals the response, we can read arbitrary files from the web application’s host.
Gopher
Gopher is a protocol still supported by agents like curl, and we can use
gopher to craft HTTP requests with different methods, allowing us to send HTTP
request methods to backend targets other than the methods allowed by the
vulnerable web application, e.g. GET.
For example, if we can provide an arbitrary URL to a web application vulnerable to SSRF, we can provide a gopher URL, providing the method and headers we want to specify for the request:
curl gopher://127.0.0.1:80/_POST%20/status%20HTTP/1.1%0a%0aAnd we can use characters like %0a to create newlines as necessary for our
headers in the request.