HTTP Redirects should not count as new vulnerabilities
Problem to solve
Websites often employ HTTP redirects to take users to a new location on the website. A common example of this is when a user accesses a page that requires login, the user will be redirected to the login page.
When DAST encounters a redirect, it follows the redirect so that it can spider the following page. The the following page contains a vulnerability, then the Security Dashboard will show two vulnerabilities: one for the original path that triggered the redirect, and one for the path whether the redirect directed the user to.
One of these vulnerabilities is possibly a True Positive, the rest are Duplicate Findings.
Intended users
How to reproduce this
Create an nginx
configuration, nginx.conf
:
server {
root /usr/share/nginx/html;
listen 80;
server_name localhost;
types { } default_type "application/json";
# redirect from root URLs
rewrite ^/$ /v1 redirect;
rewrite ^/v1$ /v1/trees redirect;
# GET/POST /v1/tree/:tree_id
location = /v1/trees {
set $BODY '{"payment": "Please pay using your American Express Credit Card with number 3782 8224 6310005."';
return 200 $BODY;
limit_except GET POST { deny all; }
}
}
Run a Docker server:
docker run --rm -v "${PWD}/nginx.conf":/etc/nginx/conf.d/default.conf -p 80:80 -d nginx:1.17.6-alpine >/dev/null
Run a DAST scan against http://[your-ip-address]
. After running, the Security Dashboard will show PII Scanner
vulnerabilities for every redirect.
Proposal
After scanning is complete,
- DAST finds requests made by ZAP that were redirects
- DAST checks to see if vulnerabilities created at both the original page and the redirect page are the same
- If so, DAST removes duplicate vulnerabilities, leaving the path as the redirect page
- Non-duplicate vulnerabilities are written to the DAST JSON report
Complications:
- This should work when a page is redirected multiple times
- DAST should not get stuck in a redirect loop.