Sensitive files exposed due to SSRF

Q: What is the purpose of the "FETCH_SENSITIVE_FILES" array in this test

The "FETCH_SENSITIVE_FILES" array is used to identify and exploit a vulnerability known as Server Side Request Forgery (SSRF). It replays the original request by replacing the URI parameter with popular sensitive file paths, and checks if the application responds with a 2XX success code and provides details of these files.

Q: How does the test determine if the endpoint is vulnerable to SSRF

The test determines if the endpoint is vulnerable to SSRF by modifying the query and body parameters of the request to include the sensitive file paths specified in the "filePaths" word list. If the modified request receives a 2XX success code and the response payload contains certain keywords like "daemon", "Linux", "Ubuntu", or "/proc/self/cmdline", it indicates a potential SSRF vulnerability.

Q: What is the impact of successfully exploiting the SSRF vulnerability

Successful exploitation of the SSRF vulnerability can compromise sensitive data such as passwords, source code, and confidential files. It allows an attacker to make requests to internal resources that are normally inaccessible, potentially leading to further attacks or unauthorized access.

Q: What are some common concepts in application development that can increase the risk of SSRF attacks

Some common concepts in application development that can increase the risk of SSRF attacks include webhooks, fetching files from URLs, custom single sign-on (SSO) implementations, and URL previews. These concepts often involve accessing external resources based on user input, which can be manipulated by an attacker to perform SSRF attacks.

Q: Why are modern technologies like cloud providers, Kubernetes, and Docker more susceptible to SSRF attacks

Modern technologies like cloud providers, Kubernetes, and Docker expose management and control channels over HTTP on predictable, well-known paths. These channels become easy targets for SSRF attacks because they allow an attacker to make requests to internal resources within the infrastructure. Additionally, the connected nature of modern applications makes it more challenging to limit outbound traffic, making it easier for an attacker to exploit SSRF vulnerabilities.

Home

Test

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)

Impact of the vulnerability

Successful exploitation might compromise sensitive data such as passwords, source-code, confidential files etc.

How this template works

APIs Selection

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.

Execute request

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.

Validation

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

Loved by security teams!

"We are absolutely thrilled with the testing feature of Akto. We have used it on our graphQL endpoints and it performs flawlessly identifying common API security issues. It's truly a game-changer and we highly recommend Akto to anyone looking to effortlessly secure their API endpoints. With a user-friendly interface, it's the perfect solution for anyone looking to embrace custom rules with context to reduce false positives."

Security team,

Loom

Security team,

Loom

Security team,

Loom

"The text editor in Akto is absolutely remarkable. Its user-friendly YAML format strikes the perfect balance between simplicity and power. With intuitive features like 'API selection filter', 'Execute', Validate' creating test rules becomes incredibly easy. Akto's test editor is a game-changer, enabling seamless creation of highly personalized and effective tests that could meet the needs of any modern day organization. "

Security team,

Rippling

Security team,

Rippling

Security team,

Rippling

Explore other tests

Port scanning with SSRF

Sensitive AWS details exposed via replacing url param with encoded url due to SSRF

Sensitive AWS details exposed due to SSRF

Sensitive AWS details exposed via replacing CSV param due to SSRF

Sensitive AWS details exposed via replacing file param due to SSRF

Sensitive AWS details exposed via replacing image param due to SSRF

Sensitive localhost details exposed via replacing URI param with localhost/admin due to SSRF

Sensitive localhost details exposed via replacing URI param redirecting to localhost/admin due to SSRF

Sensitive localhost details exposed via replacing URI param to encoded localhost/admin due to SSRF

Sensitive AWS details exposed via replace PDF param due to SSRF

Sensitive AWS details exposed via replacing XML param due to SSRF

Learn more:

Content

7 min read

Server-Side Request Forgery: Proactive SSRF Prevention Tactics for Developers

Content

7 min read

Server-Side Request Forgery: Proactive SSRF Prevention Tactics for Developers

Suggest API security tests

We're actively building the test library. Suggest a test! If we like your suggestion, you will see it in the library in few days.