DAST vulnerabilities show more information about the request
Problem to solve
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.