## 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](https://handbook.gitlab.com/handbook/engineering/infrastructure/platforms/tools/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 - **PM**: @abellucci - **EM**: @mikeeddington - **UX/PDM**: [Name] <!-- also add as assignee to this epic --> - **Group(s)**: ~"group::dynamic analysis" - **Engineering Owner**: @rvider #### Initiative Driver - Product or Engineering? - [x] **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 :bulb: _See additional details about this process at https://handbook.gitlab.com/handbook/product-development/r-and-d-interlock/ ##### :one: Pre-Interlock - [x] Update epic description with all relevant information - [x] Ensure all dependencies are identified - [ ] Apply appropriate labels (see below) - [ ] Apply target delivery Milestone - [ ] Update interlock status as discussions progress (via label) ##### :two: 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 <!-- Apply appropriate labels: - [x] Section (section::dev, section::ops, section::sec) - [x] Stage (devops::plan, devops::create, devops::verify, etc.) - [x] Group (group::product planning, group::project management, etc.) - [ ] Interlock Priority (Product labels = Interlock Priority::P1, Interlock Priority::P2, Interlock Priority::P3, Engineering labels = Interlock Priority::E1, Interlock Priority::E2, Interlock Priority::E3) - [x] Investment theme (Investment theme::Core-Devops, Investment theme::Security-Compliance, Investment theme::AI across SDLC) - [x] Platforms (platform: GitLab.com, platform: dedicated, platform: dedicated for gov, platform: self-managed) - [x] Subscription tier (GitLab Ultimate, GitLab Premium, GitLab Free) - [x] Quarter (FY27 Q1, FY27 Q2, FY27 Q3, FY27 Q4) - [ ] Pre-interlock status label (interlock status::New/Proposal in progress, interlock status::cancelled, etc) - [ ] Post-interlock status label (R&D roadmap status::Executing, R&D roadmap status::Completed) - [ ] Post-interlock, once quarter begins update health weekly (health::on track, health::needs attention, health::at risk) *For guidance on labels, see the [labels guide here](https://handbook.gitlab.com/handbook/product-development/r-and-d-interlock/#labels-guide) --> #### 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. ```mermaid 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 * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst) ### References https://gitlab.com/gitlab-org/gitlab/-/issues/223783 ### 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](https://about.gitlab.com/handbook/product/pricing/#four-tiers) ### Links / references