Sensitive AWS details exposed via replace PDF param due to SSRF
The endpoint appears to be vulnerable to Server Side Request Forgery attack. The original request was replayed by replacing PDF 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 API requests to be executed. 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 ".pdf" value.
The template specifies a single request to be executed. It modifies the query parameter and body parameter named "pdf_key" by replacing it with a URL that redirects to an AWS IMDS endpoint. This is done to simulate a Server Side Request Forgery (SSRF) attack.
The template includes 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 specified sensitive AWS information, such as "ami-id" or "block-device-mapping". If the validation criteria are met, it indicates a successful exploitation of the SSRF vulnerability.
Frequently asked questions
What is the purpose of this test
How does SSRF vulnerability occur
What are some common scenarios that make SSRF more prevalent
Why is SSRF considered more dangerous in modern technologies
Why is it challenging to limit outbound traffic from modern applications
How should protection mechanisms against SSRF be chosen