Sensitive files exposed due to SSRF
The endpoint appears to be vulnerable to Server Side Request Forgery attack. The original request was replayed by replacing the URI parameter with popular sensitive file paths. The application responded with 2XX success code and also gave out details of these files.
Server Side Request Forgery (SSRF)
How this template works
The API selection filters in this template are used to identify potential SSRF vulnerabilities by checking if the request payload or query parameters contain URLs. It uses the "contains_either" keyword to match URLs that contain "http" in either the request payload or query parameters.
The execute section of the template specifies the actions to be performed on the identified URLs. In this case, it modifies the query and body parameters by replacing them with the file paths specified in the "filePaths" word list.
The validation section defines the criteria for determining if the SSRF vulnerability has been successfully exploited. It checks if the response code is between 200 and 300 (indicating a successful request) and if the response payload contains any of the specified keywords such as "daemon", "Linux", "Ubuntu", or "/proc/self/cmdline". If these conditions are met, it suggests that sensitive files have been exposed due to SSRF.
Frequently asked questions
What is the purpose of the "FETCH_SENSITIVE_FILES" array in this test
How does the test determine if the endpoint is vulnerable to SSRF
What is the impact of successfully exploiting the SSRF vulnerability
What are some common concepts in application development that can increase the risk of SSRF attacks
Why are modern technologies like cloud providers, Kubernetes, and Docker more susceptible to SSRF attacks
Can the SSRF risk be completely eliminated? What factors should be considered when choosing a protection mechanism