## 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 - External dependencies: None #### DRIs - **PM**: @joelpatterson - **EM**: @mikeeddington - **UX/PDM**: \[Name\] <!--also add as assignee to this epic--> - **Group(s)**: gitlab~10690741 - **Engineering Owner**: @rvider #### 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