Discovery: Fix DAST SSRF vulnerability rules for ZAP
Problem to solve
SSRF (Server-side request forgery) attacks work by getting an application server to call an injected HTTP URL of the attackers choice, leading to unauthorized actions or data breaches.
DAST tests for SSRF vulnerabilities by starting a local server, attempting to inject the URL to the local server, and seeing if it receives any HTTP calls.
Unfortunately, DAST runs in a Docker container on a GitLab Runner. Neither of these will expose the port of the local server, and ZAP will not know the public IP address of the GitLab Runner. These vulnerability checks will never find vulnerabilities.
This issue proposes to fix this issue or disable the checks.
Intended users
Proposal
- Work out of this is possible when running on a GitLab Runner, hitting an external target URL.
- How would we know the IP address of the runner?
- Can we expose the port?
- Is this safe to do? (shared runners: no, private runners in a self-hosted instance?)
- Can ZAP be configured to always use the same port number?
- Figure out which vulnerability checks start a local server
- If DAST is testing a service defined in the
.gitlab-ci.yml
file, will these checks work?- Do GitLab runners put them on the same network? How do we set the domain name of the local server to ZAP?
- If none of the above options are feasible, should we just disable the vulnerability checks?
Further details
Permissions and Security
Documentation
Availability & Testing
What is the type of buyer?
Edited by Seth Berger