ZAP result - CORS misconfiguration

[andrew-jameson]

Description:
Follow on to #2663, we need to address a potential CORS misconfiguration as is getting flagged by our new ZAP scan results

Acceptance Criteria:
Create a list of functional outcomes that must be achieved to complete this issue

• OWASP ZAP scan results do not contain CORS misconfiguration alert
• Testing Checklist has been run and all tests pass
• README is updated, if necessary

Tasks:
Create a list of granular, specific work items that must be completed to deliver the desired outcomes of this issue

• Root cause analysis on CORS failure
• Update CORS configurations for resolution
• Test fixes w/ ACF domain prior to merging
• Run Testing Checklist and confirm all tests pass

Notes:
Add additional useful information, such as related issues and functionality that isn't covered by this specific issue, and other considerations that will be helpful for anyone reading this

Supporting Documentation:
Please include any relevant log snippets/files/screen shots

Open Questions:
Please include any questions or decisions that must be made before beginning work or to confidently call this issue complete

[George-Hudson]

@ADPennington @andrew-jameson @Smithh-Co After reviewing the CORS failure, it seems like this only happens from my ZAP scan update branch which can be seen here on the circleci run in the generated report.

This nightly run was run against my branch, as opposed to the standard develop branch, just to test that our proposed IGNORE of the Active SQL allowed for the tests we didn't want to run to be skipped.

After reviewing my changes in the branch, I can see no where that we are messing with the CORS configuration. This CORS misconfiguration failure is not happening in any of the develop, staging, or production runs, and we are just seeing the unwanted Active SQL test failures.

I believe the issue we are seeing is only due to running the nightly scan against a non-standard branch and should be a non-issue once merged into develop. I can be on hand to review the nightly scan against develop as soon as my PR merges to ensure this is the case and revert if I am wrong.

[George-Hudson]

So the thing I was thinking couldn't happen happened:
https://app.circleci.com/pipelines/github/raft-tech/TANF-app/15902/workflows/496a8671-135a-4c2d-b430-bd1efa2d7a7f/jobs/47545
https://output.circle-artifacts.com/output/job/16a551a4-7fa2-4291-8682-b471ad3c8f69/artifacts/0/tdrs-frontend/reports/owasp_report.html
Why would these not show up before we IGNORED the Active SQL Injection attacks...

Trying to understand, but maybe the spiders have more resources to explore other things. https://www.zaproxy.org/faq/why-can-zap-scans-be-inconsistent/

So I think it is still valid to IGNORE the Active SQL issues. But yeah, maybe a deeper dive on this ticket is necessary.

[George-Hudson]

@andrew-jameson @ADPennington I feel we should schedule this ticket into the backlog based on agreed upon priorities. It looks at first glance that these errors coming up are not valid concerns, but I think each of the issues ZAP is bringing up as a concern should be given due diligence and then either fixing them if they are valid, or IGNOREing them like we did with the Active SQL issues.

However, due to how the web-crawlers work, once we get through these CORS misconfiguration concerns, I think the same thing might happen where the web-crawlers then find some new concern. I think this is because they have more time to explore different areas.

In order for this tool to be effective, we need to get the configuration whittled down to something that really matters to our app. The last thing we want from a tool like this is for it to be too noisy (as it is right now) with reporting false positives and we don't trust it. If it does find something of real concern to us, we might miss it for a long time because ZAP has been crying wolf for too long.

[raftmsohani]

FACT: We see CORS misconfig failure in Prod and Staging, but not in dev.

The reason we don't see CORS misconfig in the scan results is we are ignoring the URL scheme using:

 -config globalexcludeurl.url_list.url\(15\).regex='^https:\/\/.*\.cloud.gov\/.*$' \

So in order to allow crowler to scan all urls from cloud.gov domain, we need to change this regex to only match the unwanted URLs

[ADPennington]

noticing non-tdp urls in the qasp-label scan too.