Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

2238 document unsafe-inline exception #2941

Merged
merged 17 commits into from
May 20, 2024
Merged

2238 document unsafe-inline exception #2941

merged 17 commits into from
May 20, 2024

Conversation

jtimpe
Copy link

@jtimpe jtimpe commented Apr 12, 2024

Summary of Changes

Pull request closes #2238
Pull request closes #2843

Upon further investigation, the following low priority findings no longer show up in our latest Webinspect scans

  • HTML5: CORS Prolonged Caching of Preflight Response
  • HTML5: CORS Unsafe Methods Allowed

I have removed the changes associated with those findings and instead only addressed the final one

  • HTML5: Misconfigured Content Security Policy

Since our Kibana implementation requires being served behind a proxy, the unsafe-eval and unsafe-inline directives mentioned by the scan are required. I've included some documentation in ADR 16 to reflect this.

How to Test

List the steps to test the PR
These steps are generic, please adjust as necessary.

cd tdrs-frontend && docker-compose -f docker-compose.yml -f docker-compose.local.yml up -d
cd tdrs-backend && docker-compose -f docker-compose.yml -f docker-compose.local.yml up -d 
  1. Open http://localhost:3000/ and sign in.
  2. Proceed with functional tests as described herein.
  3. Test steps should be captured in the demo GIF(s) and/or screenshots below.

Demo GIF(s) and screenshots for testing procedure

Deliverables

More details on how deliverables herein are assessed included here.

Deliverable 1: Accepted Features

Checklist of ACs:

  • ADR 16 updated to capture new scenarios where unsafe-* policies are in-use
  • ADR 16 updated to capture security scanning tools that are flagging unsafe-* policies
  • lfrohlich and/or adpennington confirmed that ACs are met.

Deliverable 2: Tested Code

  • Are all areas of code introduced in this PR meaningfully tested?
    • If this PR introduces backend code changes, are they meaningfully tested?
    • If this PR introduces frontend code changes, are they meaningfully tested?
  • Are code coverage minimums met?
    • Frontend coverage: [insert coverage %] (see CodeCov Report comment in PR)
    • Backend coverage: [insert coverage %] (see CodeCov Report comment in PR)

Deliverable 3: Properly Styled Code

  • Are backend code style checks passing on CircleCI?
  • Are frontend code style checks passing on CircleCI?
  • Are code maintainability principles being followed?

Deliverable 4: Accessible

  • Does this PR complete the epic?
  • Are links included to any other gov-approved PRs associated with epic?
  • Does PR include documentation for Raft's a11y review?
  • Did automated and manual testing with iamjolly and ttran-hub using Accessibility Insights reveal any errors introduced in this PR?

Deliverable 5: Deployed

  • Was the code successfully deployed via automated CircleCI process to development on Cloud.gov?

Deliverable 6: Documented

  • Does this PR provide background for why coding decisions were made?
  • If this PR introduces backend code, is that code easy to understand and sufficiently documented, both inline and overall?
  • If this PR introduces frontend code, is that code easy to understand and sufficiently documented, both inline and overall?
  • If this PR introduces dependencies, are their licenses documented?
  • Can reviewer explain and take ownership of these elements presented in this code review?

Deliverable 7: Secure

  • Does the OWASP Scan pass on CircleCI?
  • Do manual code review and manual testing detect any new security issues?
  • If new issues detected, is investigation and/or remediation plan documented?

Deliverable 8: User Research

Research product(s) clearly articulate(s):

  • the purpose of the research
  • methods used to conduct the research
  • who participated in the research
  • what was tested and how
  • impact of research on TDP
  • (if applicable) final design mockups produced for TDP development

@jtimpe jtimpe added the raft review This issue is ready for raft review label Apr 12, 2024
Copy link

codecov bot commented Apr 12, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 93.11%. Comparing base (229c32c) to head (8b1b6a2).
Report is 1 commits behind head on develop.

Additional details and impacted files

Impacted file tree graph

@@           Coverage Diff            @@
##           develop    #2941   +/-   ##
========================================
  Coverage    93.11%   93.11%           
========================================
  Files          272      272           
  Lines         7055     7055           
  Branches       591      591           
========================================
  Hits          6569     6569           
  Misses         392      392           
  Partials        94       94           
Flag Coverage Δ
dev-backend 93.19% <ø> (ø)
dev-frontend 92.62% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.


Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2729026...8b1b6a2. Read the comment docs.

Copy link

@raftmsohani raftmsohani left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

need to move the unsafe-inline header to location instead of server global to limit the security implication

@raftmsohani
Copy link

changes needed:

  1. need to make the frontend to load without unsafe-inline: see this npm run build without any minification facebook/create-react-app#6643 (comment)

@raftmsohani raftmsohani added WIP and removed raft review This issue is ready for raft review labels Apr 19, 2024
@raftmsohani raftmsohani changed the title document unsafe-inline exception 2238 document unsafe-inline exception Apr 29, 2024
@raftmsohani
Copy link

UPDATE Apr 9th:
To be able to have separate CSP header for the website and for Kibana, we will need to move the CSP header assignment to /location directive. The headers that are set in .conf file cannot be overwritten in /location directive and we can only add headers. There are two separate issues with this change:

  1. TDRS website security: currently the frontend needs unsafe-inline directive in the CSP header both for style CSS files and for running .js file and finally for making axios requests. (there are a couple of solutions to this problem, but one is to separate css file into a static add and then add a token to other .js requests. This needs more investigation and work
  2. For Kibana: there is no workaround to needed unsafe-inline tag. To reduce the risk, we can move this tag to the /kibana in the location file and remove the CSP header from .conf file.

@jtimpe jtimpe added raft review This issue is ready for raft review and removed WIP labels May 6, 2024
@jtimpe jtimpe requested review from ADPennington and removed request for atrimpe and elipe17 May 8, 2024 19:10
@ADPennington
Copy link
Collaborator

per async on 5/10 with @jtimpe -- we agreed that this PR can also close #2843

@ADPennington ADPennington added raft review This issue is ready for raft review and removed QASP Review labels May 13, 2024
@raftmsohani raftmsohani added QASP Review and removed raft review This issue is ready for raft review labels May 20, 2024
set $CSP "${CSP}script-src-attr 'self' 'unsafe-inline' http://{{env "KIBANA_BASE_URL"}}:5601;";
```

Kibana performs ajax requests from its frontend to scripts hosted on the server in order to provide styling and javascript functionality - in order to serve Kibana from behind a proxy, which is a requirement with cloud.gov, these `unsafe-inline` and `unsafe-eval` directives are required. The CSP exceptions are fairly low risk as they are limited to artifacts within the Kibana domain.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jtimpe please include the links in #2843 as references. a comment from cloud.gov staff is included in this issue

@@ -22,6 +22,21 @@ When investigating, we sought out information on what other, modern ACF systems

While we also investigated and developed technical solutions utilizing either React-app-rewired or Next.js, we decided that the departure from our existing stack was not a worthwhile investment and could lead to other complications down the road.

### 2024 Update
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jtimpe can we rename this markdown to 016-security-scan-waiver.md?

@@ -22,6 +22,26 @@ When investigating, we sought out information on what other, modern ACF systems

While we also investigated and developed technical solutions utilizing either React-app-rewired or Next.js, we decided that the departure from our existing stack was not a worthwhile investment and could lead to other complications down the road.

### 2024 Update
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jtimpe @raftmsohani are any of the CSP related findings on the latest nightly scan related to what is described below? if so, we may want acknowledge that this is not just being found in webinspect but zap as well.

https://app.circleci.com/pipelines/github/raft-tech/TANF-app/24238/workflows/3faab2a5-dab3-4f52-bf56-6e321dfb9b03/jobs/71676/artifacts

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i do not believe any of those findings are related to this waiver

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ADPennington Jan is correct, they are not relevant.

On a separate note, I am creating a ticket to check for user auth, similar to what we do for Kibana auth, to prevent access to api without auth: https://tdp-frontend-develop.acf.hhs.gov/v1/users/id/

@jtimpe jtimpe requested a review from ADPennington May 20, 2024 13:56
* [elastic/kibana #27047](https://github.com/elastic/kibana/issues/27047#issuecomment-799680263) in March 2021
* an [elastic discussion post](https://discuss.elastic.co/t/does-kibana-need-the-autorisation-of-unsafe-inline-or-unsafe-eval-to-work-properly/234390/2) in May 2020

The CSP exceptions are fairly low risk as they are limited to artifacts within the Kibana domain.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jtimpe can you provide a couple of examples of what we mean by artifacts here? might also be worth explicitly stating there is no risk to data assets.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

open to ideas on how we can convey that there's no risk to data assets - what assets are specifically of concern?

* Vega (when interpreting its visualization syntax)
* Lodash (via the _.template function)

Maliciously side-loading a script would require Kibana have an unresolved persistent-XSS vulnerability, as well as file-system access to our cloud.gov Kibana application to load a script from an allowed domain. The attack vector is further limited by our authentication implementation, which requires a user be approved and granted Kibana access before loading any Kibana-related pages at all. In these cases, an attacker would have gained access to the system already.
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@elipe17 @raftmsohani i added the following note about mitigation. please double-check my logic here :)

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me!

Copy link
Collaborator

@ADPennington ADPennington left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thank you @jtimpe 🚀

```

Kibana performs ajax requests from its frontend to scripts hosted on the server in order to provide styling and javascript functionality - in order to serve Kibana from behind a proxy, which is a requirement with cloud.gov, these `unsafe-inline` and `unsafe-eval` directives are required.
We currently use Kibana version 7.4 [released October, 2019](https://www.elastic.co/blog/kibana-7-4-0-released). This requirement is present in our current version as mentioned by the Elastic team in
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cloud.gov is actually running elastic/kibana 7.10 now!

@jtimpe jtimpe merged commit f1ef9d1 into develop May 20, 2024
16 checks passed
@jtimpe jtimpe deleted the fix/2238-webinspect-low branch May 20, 2024 20:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants