DAST Site Validation design
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 two ways, either through a .txt file added to the root of their site or via a meta tag on the index/start/home page of the target URL.
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 two options:
- Text file validation
- Meta tag 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 upload the file to the root of the site that they specified as the "target URL".
- 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]">
. They should be instructed to put the meta tag on the index/start/home page for the URL they want to test. - Once either 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.
- 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.
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.
Links / references
Tasks:
-
Explore and define MVC solution -
Identify areas for opportunity beyond the MVC -
Create validation issues for new features and ideas
-
-
Gather feedback on design direction and proposal (On going stage now) -
Finalise MVC mocks and experience -
Finalise edge-cases and empty states -
Finalise Copy/review with copy writer -
finalise description with design deliverables -
Post design specs