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

• Sasha (Software Developer)
• Sam (Security Analyst)

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?

Gold/Ultimate