## Problem GitLab DAST currently uses OWASP ZAP as our DAST API scanner. There are many issues with ZAP that are difficult for us to solve directly, such as adding new API definitions, authentication, false positives, memory usage, and scan time. As ZAP is an open source project with an older code base and architecture, adding new features can be difficult and requires more consideration than adding onto an in-house product. Another issue is that we do not control the roadmap or direction of ZAP and it might diverge from GitLab's needs. By using Peach as our API scanner, we can directly control what the roadmap is and how this roadmap is implemented. ## Proposal The current proposal is to integrate Peach API Security into DAST as a new scanner that will replace the ZAP API scanner once the feature set and vulnerability detection can be verified as being equal or greater than ZAP. - [x] 1: Benchmark both ZAP and Peach against the same vulnerable API to determine the coverage of the checks/rules that are in both products. https://gitlab.com/gitlab-org/secure/vulnerability-research/awesomesauce/-/issues/19 - Sample projects to benchmark will live here: https://gitlab.com/gitlab-org/security-products/demos/api-dast - [x] 2: Do a full evaluation of the feature set, to determine what areas would need to be focused on to match the current ZAP API feature set: https://gitlab.com/gitlab-org/gitlab/-/issues/241259 - [x] 3. Integrate Peach into DAST and allow users to enable it as a "beta" scanner until we are certain that the detection and feature capabilities meet the current capabilities: https://gitlab.com/gitlab-org/gitlab/-/issues/241258 - POC: https://gitlab.com/gitlab-org/security-products/demos/dast-peachapi-poc ## Capabilities Functionality differences between Peach API and ZAP. 1. Peach supports testing multiple endpoints at once. This is useful when dealing with micro services, or interdependent services. Configurations can be different for each endpoint, or in the case of multiple services being exposed through a reverse proxy, by path. Different configurations is useful when mixed technology is used. Service A might be NodeJs, while service B is Python Flask. 1. Peach supports testing related HTTP requests together. For example, a set of operations might create a resource, use the resource, and then delete the resource. Testing these together has a higher likely hood of producing results. When using test framework integration this happens automatically. 1. Peach can, optionally, perform log analysis during testing to improve detection of vulnerabilities. 1. Peach generates Postman Collections for reporting vulnerabilities to aid in quick reproduction of issues 1. A number of options exist to provide API endpoints to peach: 1. OpenAPI specifications (also supported by ZAP) 1. HTTP Archive (HAR) 1. Postman Collections - [ ] 1. BURP Projects - [ ] 1. Proxying command line tools/scripts - [ ] 1. Test suite integration (JUnit, pytest, scalatest, ...) - [ ] 1. Selenium integration examples - [ ] 1. Custom integrations using SDK libraries (Python, Java, C#, JS) 1. Authentication handled in multiple places- 1. If message contents impact the auth (signed requests) post processing scripts 1. Otherwise cached and injected with ability to renew when auth expires 1. All of Peach API's checks are written from the viewpoint of API testing, not frontend testing. 1. Peach API supports more web API technologies: 1. SOAP (using HAR/Postman, not WSDL) 1. GraphQL (using HAR/Postman, not schema) 1. [unreleased] gRPC 1. REST API 1. FormBody 1. Generic XML/JSON 1. [Vulnerability Check Comparison with ZAP and Peach ](https://docs.google.com/spreadsheets/d/13UDp2T1fAG1lYWBsPzhFgKCbWbOcOooiH-7wN4z8A3A/edit#gid=1611529108) ## Integration Plan This captures how the actual integration would occur and the technical work to enable it. This doesn't include any new capabilities needed to reach parity with ZAP, just the integration work. MVC integration with DAST can be done through CI Template changes using the existing DAST configuration variables. Peach already supports OpenAPI specifications and methods to pass target URL used by DAST. The security report Peach outputs uses the DAST schema. List of work items: - [x] Update DAST CI template to use Peach when API testing performed. Rules can be used to turn on/off jobs in the DAST CI template based on the presence of the `DAST_API_SPECIFICATION` variable. https://gitlab.com/gitlab-org/gitlab/-/issues/284683 - [ ] Documentation updates. Re-use existing/planned documentation when possible. https://gitlab.com/gitlab-org/gitlab/-/issues/284850 - [x] Split DAST API into it's own documentation - [ ] Use API Fuzzing doc contents - [ ] Use configuration file docs from API Fuzzing - [ ] Migration guide - [ ] 1. Create yaml configuration file for DAST usage https://gitlab.com/gitlab-org/gitlab/-/issues/284697 - [ ] 1. Update `worker-entry` to support DAST environment variables https://gitlab.com/gitlab-org/gitlab/-/issues/284917 - [ ] 1. Support both `DAST_API_` and `FUZZAPI_` prefixes - [ ] 1. Add `DAST_API_SPECIFICATION` as alias to `DAST_API_OPENAPI` - [ ] 1. Add `DAST_API_HOST_OVERRIDE` as alias to `DAST_API_TARGET_URL` - [ ] 1. Add `DAST_REQUEST_HEADERS`, convert to `-H` argument to `runner` - [ ] Update log messages to be agnostic to fuzzing/dast https://gitlab.com/gitlab-org/gitlab/-/issues/284932 - [x] Make sure fuzzing UX work for vulnerability details page works with API DAST - Frontend team engineer says the work being done is keyed off fields existing and will work for both report types. - [x] Create or update sample projects https://gitlab.com/gitlab-org/gitlab/-/issues/284933 - [ ] Deprecate use of `DAST_API_SPECIFICATION` and adopt `DAST_API_OPENAPI`. https://gitlab.com/gitlab-org/gitlab/-/issues/290241 Bonus, but not required for MVC: 1. Create API DAST configuration files for common tech stacks