Feature/disallowed domains in csp

[noamblitz]

Changes

Add bit that checks for disallowed domains in csp header
Add bit that asks the relevant question

Issue link

Closes #2571

TO DO: unit test

---

Code Checklist

• All the commits in this PR are properly PGP-signed and verified.
• This PR only contains functionality relevant to the issue; tickets have been created for newly discovered issues.
• I have written unit tests for the changes or fixes I made.
• For any non-trivial functionality, I have added integration and/or end-to-end tests.
• I have performed a self-review of my code and refactored it to the best of my abilities.

Communication

• I have informed others of any required .env changes files if required and changed the .env-dist accordingly.
• I have made corresponding changes to the documentation, if necessary.
• I have included comments in the code to elaborate on what is not self-evident from the code itself, including references to issues and discussions online, or implicit behavior of an interface.

---

Checklist for code reviewers:

Copy-paste the checklist from the docs/source/templates folder into your comment.

---

Checklist for QA:

Copy-paste the checklist from the docs/source/templates folder into your comment.

[noamblitz]

Unfortunately, something goes wrong in rocky which causes an error on submitting the form with booleans instead of strings

[ammar92]

Nice one, almost there! If you implement te test like this (pseudocode):

assert results = [ KATFindingType, Finding ]

This way you also verify the length and order for free 👍

[ammar92]

I fixed the merge conflict, should be testable now

[stephanie0x00]

Checklist for QA:

• I have checked out this branch, and successfully ran a fresh make reset.
• I confirmed that there are no unintended functional regressions in this branch:
  • I have managed to pass the onboarding flow
  • Objects and Findings are created properly
  • Tasks are created and completed properly
• I confirmed that the PR's advertised feature or hotfix works as intended.

What works:

• Manually adding a CSP header for an existing site/host with a bad domain in it triggers the vulnerability as shown below. Couldn't verify with just an IP-address as it's currently not possible to generate a HTTPResource without a hostname. The finding is shown below:

What doesn't work:

n/a

Bug or feature?:

• Do we want this feature added to the CSP compliance checklist in the Web report? I don't think it is added right now.

[underdarknl]

I would expect the report to say 'CSP header present 1/1` but then not list the CSP as secure in the following line so '0/1'.

[noamblitz]

Lets create a ticket to add this to the report. Since it was not part of the original ticket i think its not a good idea to let this PR hang on it.