DAST Site validation implementation for Text File Upload [parent issue]
Problem to solve
As a site owner, I want to be able to validate that I own my site and am authorized to perform active DAST scans against my site, so that I can I can both fully test my site with an active scan and prevent anyone else from using GitLab DAST to attack my site.
Intended users
- Parker (Product Manager)
- Delaney (Development Team Lead)
- Sasha (Software Developer)
- Devon (DevOps Engineer)
- Sidney (Systems Administrator)
- Sam (Security Analyst)
- Allison (Application Ops)
User experience goal
The user should be able to validate that they own their site via one of three ways: through a .txt file added to the root of their site, through an HTTP header added to their server, or via a meta tag on a page within their site.
Proposal
- If the site is not already validated, this process should be initiated via a button under the "Target URL" text box.
- If the site is already validated, the button should be replaced by text to indicate that the site is validated
- Once the process is initiated, the user should be presented with three options:
- Text file validation <- 13.4 scope
- Meta tag validation
- HTTP Header validation
- If the text file validation is selected, they should be presented with an option to download a .txt file that is named using a unique id that was generated for that individual site in that individual project. The content of the txt file should also only be that unique id. The user should be instructed to provide the path to the text file, using the target URL as the hostname.
- If meta tag validation is selected, they should be presented with the code for a meta tag that contains the same unique id that they would be given in the .txt file. The meta tag should look like:
<meta name="gitlab-dast-validation" content="[unique-dast-id]">
. The user should be instructed to provide the path to the page with the meta tag, using the target URL as the hostname. - If HTTP header validation is selected, they should be presented with the header name and value to be added to their server. The header should look like 'gitlab-dast-validation:[unique-dast-id]`. The user should be instructed to provide the path a page that will serve up that header, using the target URL as the hostname.
- Once any of those processes are finished, the user should be able to come back to the Site profile and click on a "Validate my site" button.
- GitLab attempts to validate the site by looking for either of those elements.
- If successful, the site is marked as "Validated" and the user can run active tests on it.
- The validation code will no longer be required on the site and the user can remove it.
Design
Since site validation is part of site profile creation. It is just a part outside of site profile creation.
- Site Validation design issue
- Creation site profile flow:
Further details
More discovery will need to happen around how this validation can be done automatically with review apps, so that the user doesn't need to do any work with it.
Permissions and Security
Anyone with permission to create a site profile should be allowed to validate that site.
Documentation
- The documentation in https://docs.gitlab.com/ee/user/application_security/dast/#domain-validation will need to be updated to reflect this new process of domain validation.
- A deprecation notice should go out that we are removing the old, insecure way of validating domains and site ownership.
Is this a cross-stage feature?
No, this is not a cross-stage feature.
Implementation plan
GraphQL
Create Token
mutation dastSiteTokenCreate($projectFullPath: ID!, $targetUrl: String!) {
dastSiteTokenCreate(
input: { fullPath: $projectFullPath, targetUrl: $targetUrl }
) {
id
token
status
errors
}
}
Create Site Validation
mutation dastSiteValidationCreate(
$projectFullPath: ID!
$dastSiteTokenId: DastSiteTokenID!
$validationPath: String!
$validationStrategy: DastSiteValidationStrategyEnum
) {
dastSiteValidationCreate(
input: {
fullPath: $projectFullPath
dastSiteTokenId: $dastSiteTokenId
validationPath: $validationPath
strategy: $validationStrategy
}
) {
id
status
errors
}
}
Query Site Validation Status
query project($fullPath: ID!, $targetUrl: String!) {
project(fullPath: $fullPath) {
dastSiteValidation(targetUrl: $targetUrl) {
id
status
}
}
}
Issues
Cross Cutting
- Rollout feature Flag: #238580 (closed)
frontend
- Add Validation Component: #238577 (closed)
- Hook up Profile Validation: #238578 (closed)
- Improve validation path handling: #247106 (closed)
backend
- Model Layer #245208 (closed)
- Add DastSiteValidationWorker #245209 (closed)
- Update Ci::RunDastScanService to reject unvalidated DastSites #245210 (closed)
- Add dastSiteTokenCreate mutation #245211 (closed)
- Add dastSiteValidationCreate mutation #245212 (closed)
- Add project.dastSiteValidation query #245213 (closed)
- Replace stubbed status in project.dastSiteProfile #245214 (closed)