DAST: Record and replay session
Problem to solve
Websites targeted by DAST can be complex and spidering could miss some key aspects or part of the application, especially when pages are using a lot of javascript. Therefore, DAST results can be incomplete, and even if we report the spidered URLS, it's impossible to tell what workflow was tested on these pages.
Intended users
- Delaney (Development Team Lead)
- Sasha (Software Developer)
- Devon (DevOps Engineer)
- Sam (Security Analyst)
Further details
Some DAST commercial solutions provide a way to record sessions to be replayed during the scan.
It's a great way to limit the scope of the analysis, but also it allows to replay complex workflows.
Currently, the only workflow available is authentication.
Auth will not work if the login form isn't part of the DAST_AUTH_URL
page. For example, a site where the user has to enter their email on a page, submit, and then enter their password, will not be supported by DAST.
Proposal
Let users record sessions and replay them during DAST, instead of spidering the site. The session could be a file in the repo that would be specified in the DAST job. If present, this var disables the spidering.
Moon shot
If users can provide a DAST session to run, we can imagine having multiple DAST jobs running in parallel (or not, based on a var). If the profiles don't modify the application state, it's safe to run them in parallel to save time. If we could map updated code to sessions, we could also only run the required ones.
Permissions and Security
TODO
Documentation
https://docs.gitlab.com/ee/user/application_security/dast/#authenticated-scan to be updated.
Testing
TBD
What does success look like, and how can we measure that?
More DAST jobs running, because we can support more cases.