Sensitive AWS details exposed via replacing CSV param due to SSRF
The endpoint appears to be vulnerable to Server Side Request Forgery attack. The original request was replayed by replacing CSV upload parameter with url that redirects to AWS IMDS endpoint. The application responded with 2XX success code and also gave out sensitive AWS information in response.
Server Side Request Forgery (SSRF)
How this template works
The template uses API selection filters to specify the criteria for selecting the APIs to be tested. In this case, the filters include checking the response code to be between 200 and 204, and checking if the request payload or query parameter contains a ".csv" file.
The template specifies a single request to be executed. It modifies the query parameter and body parameter named "csv_key" by replacing it with a URL that redirects to the AWS IMDS endpoint. This is done to simulate a Server Side Request Forgery (SSRF) attack.
The template defines the validation criteria for the response. It checks if the response code is between 200 and 299, indicating a successful request. It also checks if the response payload contains any of the sensitive AWS information, such as "ami-id" or "block-device-mapping". If the validation criteria are met, it indicates a potential vulnerability.
Frequently asked questions
What is the purpose of the SSRF_ON_CSV_UPLOAD test in this array
How does an SSRF vulnerability occur in an API
What are some modern concepts in application development that make SSRF attacks more common
Why are SSRF attacks more dangerous in modern technologies like cloud providers, Kubernetes, and Docker
Can the SSRF risk be completely eliminated
What is the potential impact of successfully exploiting the SSRF_ON_CSV_UPLOAD vulnerability