Skip to content
GitLab
Next
Closed
Issue created by Cameron Swords@cam_swordsDeveloper1 of 10 checklist items completed1/10 checklist items

DAST vulnerabilities show more information about the request - modal

Problem to solve

This issue tracks updating the vulnerability modal. Related to #217368 (closed) which updates the standalone vulnerability page.

A user of DAST should be able to determine the source of a vulnerability. This information can be used to dismiss false positives, or resolve the vulnerability by making a change in the source code.

The issue #36328 (closed) will ensure that the URL and the ZAProxy "evidence" is displayed to users on the Security Dashboard, Security Pipeline view and the MR widget. While useful as a MVP, there is more information that if displayed will enable a user to investigate vulnerabilities faster and with more precision.

These information includes:

  • The request method (e.g. GET, POST, HEAD, etc)
  • The response status code (e.g. 200, 500, 404, etc)
  • All of the request headers (e.g. accept: */*)
  • All of the response headers (e.g. x-frame-options: SAMEORIGIN)

Why is this information useful?

The request method is useful because different application code typically serves different method/URLs. For example, the request to GET http://myserver.com/person would be served by different code than a request to POST http://myserver.com/person. Without the method, the user will not know which place to resolve the vulnerability.

The response status code is useful because if a server returns an error, or a redirect, then different headers/body will be returned, resulting in different vulnerabilities. For example, if the user fails to login using the DAST_AUTH_URL fields the scan may continue to run, not scanning all of the pages as intended. A redirect to login from a page intended to serve content will flag this problem.

The request and response headers are useful because they often show the cause of a vulnerability (e.g. X-Content-Type-Options Header Missing). This allows the user to verify whether or not the vulnerability is a false positive or not. Users can also add custom headers, this will allow the user to verify they were sent as intended. An example of this use case is when adding basic auth to a request.

Why not also show the body?

In theory, this is also useful. Body sizes can be extremely large, for this reason it has been left out of this issue. If it is deemed necessary, and size limits can be applied determining when it is appropriate for it to be saved and shown then a new issue will be created.

Intended users

Proposal

  • The information must be extracted from the ZAProxy scan and added to the DAST report
  • The GitLab codebase should be able to parse and save the content
  • The information should be displayed on the Security Dashboard vulnerability, Security Pipeline view, and the MR widget

What does success look like, and how can we measure that?

This improves the user experience of using DAST. Over time, this should result in an increase of people using DAST.

What is the type of buyer?

Gold

Implementation Plan

  • The request and response should be added to evidence in the DAST Report Format schema.
  • DAST should be converted to generate the JSON report based on accessing the ZAP API, not by using the generated ZAP report. This is because the ZAP report does not contain the information required that lets us obtain the request/response associated with the vulnerability.
  • DAST should add the request and response to the evidence in the JSON report.
  • When a header is present more than once in a request or a response, DAST should concatenate the header values using a comma.
  • DAST tests should be updated to include request and response output. Information that changes with each request should be normalized before comparison in the tests.
  • DAST should be released with a new minor version.
  • The DAST schema should be released with a new patch version.
  • GitLab Rails should be updated to expose the request and response information.
  • The request and response should be displayed on the Security Dashboard vulnerabilites, Pipeline Security Tab, and Merge Request widget.
  • Security products other than DAST should not expose the request/response information.

/cc @matt_wilson @sethgitlab @andyvolpe

Edited by Cameron Swords