DAST callback service endpoint

Executive Summary

A number of DAST security checks require an HTTP(S) service to be accessible to applications being scanned with our DAST offerings. These vulnerability checks: Server Side Request Forgery (SSRF), Remote File Inclusion (RFI), External XML Entity Injection (XXE), Open Redirect(s) are verified by determining if a vulnerable application can be forced to initiate an outbound request.

Due to the constraints of how DAST works with in the CI/CD pipeline, we can not guarantee that the applications we scan will be able to communicate directly with the image that we are running our DAST product from.

By providing an accessible HTTP service that our DAST tools can monitor, all of our DAST products will be able to test for these types of flaws. Given the severity levels (Critical/High) of these flaw categories, it is imperative that we offer a solution to our customers to ensure these flaws are identifiable.

Engineering Assessment

Create a public service hosted using project runway and also available as a container for self hosting. A POC has been created and also work done during the breach and attack simulation that can be re-used/improved on. Support configuration via new DAST variables.

Dependencies

  • Team dependencies: None
  • Epic/Issue dependencies - Link to dependent epics/issues via the linked items widget below for ease of drill down
  • External dependencies: None

DRIs

Initiative Driver - Product or Engineering?

  • Product-driven initiatives (P1/P2/P3) - Customer-facing features or improvements driven by Product teams that require engineering resources and commitment
    • These initiatives require a Product Priority label (P1/P2/P3)
    • They may also receive GTM tier labels (T1/T2/T3) for external communication
  • Engineering-driven initiatives (E1/E2/E3) - Internal technical improvements that may not have customer-facing components
    • These initiatives require an Engineering Priority label (E1/E2/E3)
    • They have internal visibility only and are not externally communicated
    • Examples include: technical debt reduction, infrastructure improvements, refactoring, dependency upgrades

Sizing and Funding (Optional)

  • Size: M
  • Funding Status: [Funded/Partially funded/Not funded]

Hygiene Guidelines

💡 _See additional details about this process at https://handbook.gitlab.com/handbook/product-development/r-and-d-interlock/

1️⃣ Pre-Interlock
  • Update epic description with all relevant information
  • Ensure all dependencies are identified
  • Apply appropriate labels (see below)
  • Apply target delivery Milestone
  • Update interlock status as discussions progress (via label)
2️⃣ Post-Interlock: once quarter begins
  • Update health status weekly (via label)
  • Document any newly identified risks or dependencies
  • Link to implementation epics/issues as work begins
  • Flag any scope or timeline changes immediately

Design Notes

The callback service will store the following data:

  1. User-Agent of target application being scanned
    • This may contain browser versions, or language version information
  2. IP Address of target application being scanned
  3. Time that the request was made

The callback server is made up of two planes:

  • A data plane: For accepting inbound requests from DAST targets.
    • It will also contain javascript (used for triggering XSS), php, python, ruby, xml, svg and other files that may be included into a DAST target.
  • A control plane: For requesting a keys, and retrieving data for the specific key assigned to the DASTClient.
sequenceDiagram
  DASTClient->>+Server: HMAC({auth_token}, Register)
  Server->>+DASTClient: OK {key}
  DASTClient->>+DAST Target: SSRF(https://{callback_server}/{any_path}/{key}/{payloadid})
  DAST Target->>Server: https://{callback_server}/{any_path}/{key}/{payloadid}
  DASTClient->>+Server: HMAC({auth_token}, GetPayloads {key})
  Server->>+DASTClient: Return associated URLs
  • The callback server MUST remove all associated data and de-register the key once the DASTClient requests GetPayloads.
  • The callback server should automatically remove any stale data.
    • If the GetPayloads is never requested to collect the data, it should be automatically removed after 3 days.
  • It SHOULD NOT store any data that does not have a valid, and active key configured.
  • It MAY encrypt data based on registration HMAC token.
  • It SHOULD listen on HTTPS if the callback server is in an environment where it can acquire a fully qualified domain name and a valid certificate.
  • It MAY listen on HTTP only for the data plane
  • It MUST listen on HTTPS only for the control plane

Intended users

References

#223783 (closed)

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

A user is able to configure their DAST tool of choice with a callback server that can accept HTTP(s) requests.

What is the type of buyer?

Gold/Ultimate

Links / references

Edited by Michael Eddington