Add ability to validate sites for on-demand DAST
What does this MR do?
this merge request adds new functionality that validates a dast_site_token
is specified at a given url in order to determine whether or not a user should be able to run an active
dast
scan. this is not a security feature but, instead, a "footgun" to help prevent accidentally scanning the wrong environment.
i've chosen to solve this problem with a worker, service and state machine. the state machine defines the valid state transitions, the service defines the behaviour that manages state transitions and the worker calls the service and adds some retry functionality too.
Database
% be rake db:migrate && rake db:rollback && rake db:rollback == 20200928095732 AddStateToDastSiteValidation: migrating =====================
-- add_column(:dast_site_validations, :state, :text, {:default=>:pending, :null=>false})
-> 0.0019s
== 20200928095732 AddStateToDastSiteValidation: migrated (0.0020s) ============
== 20200928100408 AddTextLimitToDastSiteValidationState: migrating ============
-- transaction_open?()
-> 0.0000s
-- execute("ALTER TABLE dast_site_validations\nADD CONSTRAINT check_283be72e9b\nCHECK ( char_length(state) <= 255 )\nNOT VALID;\n")
-> 0.0005s
-- execute("SET statement_timeout TO 0")
-> 0.0002s
-- execute("ALTER TABLE dast_site_validations VALIDATE CONSTRAINT check_283be72e9b;")
-> 0.0004s
-- execute("RESET ALL")
-> 0.0002s
== 20200928100408 AddTextLimitToDastSiteValidationState: migrated (0.0070s) ===
== 20200928100408 AddTextLimitToDastSiteValidationState: reverting ============
-- execute("ALTER TABLE dast_site_validations\nDROP CONSTRAINT IF EXISTS check_283be72e9b\n")
-> 0.0007s
== 20200928100408 AddTextLimitToDastSiteValidationState: reverted (0.0038s) ===
== 20200928095732 AddStateToDastSiteValidation: reverting =====================
-- remove_column(:dast_site_validations, :state, :text, {:default=>:pending, :null=>false})
-> 0.0012s
== 20200928095732 AddStateToDastSiteValidation: reverted (0.0024s) ============
Related Issue(s)
Does this MR meet the acceptance criteria?
Conformity
-
Changelog entry -
Documentation (if required) -
Code review guidelines -
Merge request performance guidelines -
Style guides -
Database guides -
Separation of EE specific content
Availability and Testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. -
Tested in all supported browsers -
Informed Infrastructure department of a default or new setting change, if applicable per definition of done
Security
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
-
Label as security and @ mention @gitlab-com/gl-security/appsec
-
The MR includes necessary changes to maintain consistency between UI, API, email, or other methods -
Security reports checked/validated by a reviewer from the AppSec team