Vulnerability Report request details contain secret custom request headers in plain text

HackerOne report #1783209 by joaxcar on 2022-11-24, assigned to @greg:

Report

Summary

Users can configure a DAST scanner to use custom headers to send together with requests to the tested webapp. As I have shown in other reports these headers are supposed to be hidden after configuration in for example a site profile. I have found another place where these tokens leak. I belive this is different than the other ones so I will report this separately. If it is fixed by the same fix as my other report, feel free to close this one.

When an active DAST scan is completed, there is a vulnerability report generated. This is a JSON file that is stored separately and used in multiple parts of the UI.

But they all use the same information. This report contains information on the vulnerability but also a log of the request and response made by the scanner. It can look like this

GET https://joaxcar.com  
Authorization: ********  
Cache-Control: no-cache  
Cookie: PHPSESSID=********; auth-session=********; token=********  
Host: joaxcar.com  
Pragma: no-cache  
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0  
X-some-secret-header: secret-token3  
X-token: secret-token2

<Message body is not provided>

This is using custom headers like this Authorization: Bearer token1, X-some-secret-header: secret-token3, X-token: secret-token2

You can see that it have masked my Authorization header but not my two other custom headers. These headers are now visible by any developerin the project even if they are not accessible otherwise from the UI or API (not even by the user who configured them)

Steps to reproduce

These steps here will use my site https://joaxcar.com/scan3.php which will allow a scan to be run against it and allow any username/password to authenticate

Log in as a victim user.
Create a new public project (you need Ultimate subscription)
Go to https://gitlab.com/GROUPNAME/PROJECTNAME/-/security/configuration/profile_library#site-profiles and start creating a new site profile name it site1
When you create the site profile makes sure to switch to Website.It is not important that it works out. It will leak anyway. Also make sure to add authorization in the site profile as it is needed for the job to run. Make sure to add some headers like this

Authorization: Bearer token1, X-some-secret-header: secret-token3, X-token: secret-token2

Set the Target URL and the Authorization URL to https://joaxcar.com/scan3.php , and the username and password to anything. Field names as shown in this image

Go to https://gitlab.com/GROUPNAME/PROJECTNAME/-/security/configuration/profile_library#scanner-profiles and create a new scanner profile. Check "active scan" as the mode. name it scanner1
Go to https://gitlab.com/GROUPNAME/PROJECTNAME/-/ci/editor?branch_name=main and make this your pipeline config

###  Add `dast` to your `stages:` configuration  
stages:  
  - dast

###  Include the DAST template  
include:  
  - template: DAST.gitlab-ci.yml

###  Your selected site and scanner profiles:  
dast:  
  stage: dast  
  dast_configuration:  
    site_profile: "site1"  
    scanner_profile: " scanner1 "

Click Save
Go to https://gitlab.com/GROUP/PROJECT/-/pipelines
Click the new pipeline
When the pipeline finishes refresh and click on the security tab (or add /security to the URL)
There should be a list of vulnerabilities , click the i (info button) on any of the rows to see the requests.

Alternatively download the report with the "download" button and grep in the file for the headers.

Impact

Secret headers are leaked in plain text to users who shall not have access to them. This might allow the user to get access to systems where the user should not have access.

What is the current bug behavior?

Vulnerability reports contain plain text secret headers

What is the expected correct behavior?

All custom headers should be masked as in other parts of the application

Output of checks

This bug happens on GitLab.com

Impact

Secret headers are leaked in plain text to users who shall not have access to them. This might allow the user to get access to systems where the user should not have access.

Attachments

Warning: Attachments received through HackerOne, please exercise caution!

How To Reproduce

Please add reproducibility information to this section: