Skip to content

GitLab Next

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
GitLab
GitLab
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 34,852
    • Issues 34,852
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 1,208
    • Merge Requests 1,208
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Operations
    • Operations
    • Metrics
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • GitLab.org
  • GitLabGitLab
  • Issues
  • #36332

Closed
Open
Opened Nov 14, 2019 by Cameron Swords@cam_swordsDeveloper1 of 10 tasks completed1/10 tasks

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

  • Sasha (Software Developer)
  • Sam (Security Analyst)

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

  • frontend : #215110 (closed)
  • backend : #215679 (closed)
  • 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 May 14, 2020 by Cameron Swords
Assignee
Assign to
13.1
Milestone
13.1 (Past due)
Assign milestone
Time tracking
None
Due date
None
Reference: gitlab-org/gitlab#36332