CONSOLE-4263: Add initial Content Security Policy for Console web application

[vojtechszocs]

Summary

This PR adds initial Content Security Policy implementation for Console web application.

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft, to site defacement, to malware distribution.

Initially, we will deploy CSP in report-only mode via Content-Security-Policy-Report-Only HTTP header.

CSP violations are handled explicitly via Console SecurityPolicyViolationEvent handler, which does the following:

• log the CSP event to browser console
• send the relevant CSP report data to Telemetry service

With this PR, running Console and Bridge locally with dynamic demo plugin enabled should not trigger any CSP violations.

./bin/bridge -plugins console-demo-plugin=http://localhost:9001/ -i18n-namespaces=plugin__console-demo-plugin

Note 📝 since we use Content-Security-Policy-Report-Only instead of Content-Security-Policy header, the browser may warn about Console CSP not containing report-to (standard) or report-uri (deprecated) directives as shown in the following screenshot:

This warning is not an issue, since we use a custom CSP violation event handler. The "cannot report violations" part of this warning means the browser itself will not make any CSP related HTTP requests.

The error below the warning in the screenshot is due to Console HTML index template containing an inline script tag used to set up SERVER_FLAGS and visual theme config. The proper way to address this error is to allow this script tag - either generate a SHA hash representing its contents or generate a cryptographically secure random token for the script.

Follow-up work

1. Address the above mentioned CSP inline script tag error.

2. Testing this PR has revealed that webpack generated Console assets require the following CSP exceptions, these should be removed in the future:

• script-src 'unsafe-eval' triggered by unsafe JS code like eval()
• style-src 'unsafe-inline' triggered by inline <style> elements

cc @spadgett @jhadvig

[TheRealJon]

Looks good so far to me!

[openshift-ci-robot]

@vojtechszocs: This pull request references CONSOLE-4170 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the spike to target the "4.18.0" version, but no target version was set.

In response to this:

Work in progress 🚧

TODO items

• update CSP header value with more directives as necessary
• add code to forward CSP violation data to the appropriate service
• test CSP in Firefox and Chrome

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@vojtechszocs: This pull request references CONSOLE-4170 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the spike to target the "4.18.0" version, but no target version was set.

In response to this:

Work in progress 🚧

TODO items

• update CSP header value with more directives as necessary
• add code to forward CSP violation data to the appropriate service
• test CSP in Firefox and Chrome

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@vojtechszocs: This pull request references CONSOLE-4170 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the spike to target the "4.18.0" version, but no target version was set.

In response to this:

Work in progress 🚧

TODO items

• update CSP header value with more directives as necessary
• add code to forward CSP violation data to the telemetry service
• test CSP for any reported violations in Firefox and Chrome

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@vojtechszocs: This pull request references CONSOLE-4170 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the spike to target the "4.18.0" version, but no target version was set.

In response to this:

Work in progress 🚧

TODO items

• test CSP for any reported violations and adjust CSP directives as necessary
• forward CSP violation data to the appropriate service in cspReportsHandler

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@vojtechszocs: This pull request references CONSOLE-4170 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the spike to target the "4.18.0" version, but no target version was set.

In response to this:

Summary

This PR adds initial Content Security Policy implementation for Console web application.

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft, to site defacement, to malware distribution.

Initially, we will deploy CSP in report-only mode via Content-Security-Policy-Report-Only HTTP header.

CSP violations are handled explicitly via Console SecurityPolicyViolationEvent handler, which does the following:

• log the CSP event to browser console
• send the relevant CSP report data to Telemetry service

With this PR, running Console and Bridge locally with dynamic demo plugin enabled should not trigger any CSP violations.

./bin/bridge -plugins console-demo-plugin=http://localhost:9001/ -i18n-namespaces=plugin__console-demo-plugin

Note 📝 since we use Content-Security-Policy-Report-Only instead of Content-Security-Policy header, the browser may warn about Console CSP not containing report-to (standard) or report-uri (deprecated) directives. This is not an issue, since we use a custom CSP violation event handler to send the CSP report data where appropriate.

Note 📝 we don't use report-to or report-uri directives for the following reasons:

• it's less complex to send the CSP report data where appropriate directly from Console frontend
• Console frontend gives us full control over HTTP requests (i.e. adding security headers like CSRF token as necessary)

Follow-up work

Testing this PR has revealed that webpack generated Console assets require the following CSP exceptions:

• script-src 'unsafe-eval' triggered by unsafe JS code like eval()
• style-src 'unsafe-inline' triggered by inline <style> elements

These exceptions should be removed in the future.

cc @spadgett @jhadvig

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[spadgett]

Thanks, @vojtechszocs! Happy to see progress here.

[spadgett]

Great start.

I could see some of these directives breaking plugins. As we've talked about, we'll minimally need a mechanism for plugins to add values to cspSources and a plan to transition to enforcing.

[jhadvig]

@spadgett

As we've talked about, we'll minimally need a mechanism for plugins to add values to cspSources

Sounds like an API change for the ConsolePlugin CRD

plan to transition to enforcing.

I feel like by the end of 4.18 we should have a clear picture on:

1. What the CSP which we want to enforce should look like
2. API change for the ConsolePlugin

[spadgett]

We should determine if there is a more precise way to determine if we're using a webpack dev server in development mode. There are other use cases I know of where people run an off-cluster console.

[vojtechszocs]

@spadgett @jhadvig Any ideas on how to do this detection?

My initial idea was to add a new flag that would indicate the need to allow localhost CSP sources, i.e. during Console local development.

[jhadvig]

right, I think that should be the path forward

[spadgett]

Is the violation automatically logged to the JS console as well?

We should discuss if there is a way during development mode to make it really obvious a violation occurred without the dev needing to explicitly check the console. Also we should think about the plugin development use case. We want to make sure plugin developers know they have violations that will break their plugin when we turn on enforcement.

[jhadvig]

good idea. Maybe having a similar warnings like we do have with admission webhook, but just in the DEV mode?

[vojtechszocs]

@spadgett @jhadvig I'm testing on Firefox and this is the observed behavior:

1. First, the browser logs an error about the CSP violation with brief description of the problem. However, this log entry has no details on the actual cause of the problem.
2. Then, the browser calls our custom SecurityPolicyViolationEvent handler which logs the CSP violation again, but this time with specific details.

I've chosen the Content-Security-Policy: ... log format for consistency with the browser issued log entries.

We should discuss if there is a way during development mode to make it really obvious a violation occurred without the dev needing to explicitly check the console.

👍 we could utilize toast messages or similar to notify developers of CSP problems.

Also we should think about the plugin development use case. We want to make sure plugin developers know they have violations that will break their plugin when we turn on enforcement.

Right, this is very important. Our policy must be adequate before we change Console CSP mode from report-only to enforce, otherwise we will break our plugins.

We should consider showing visual notifications whenever our CSP violation handler detects a plugin-related problem in all builds of Console frontend.

[openshift-ci-robot]

@vojtechszocs: This pull request references CONSOLE-4170 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the spike to target the "4.18.0" version, but no target version was set.

In response to this:

Summary

This PR adds initial Content Security Policy implementation for Console web application.

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft, to site defacement, to malware distribution.

Initially, we will deploy CSP in report-only mode via Content-Security-Policy-Report-Only HTTP header.

CSP violations are handled explicitly via Console SecurityPolicyViolationEvent handler, which does the following:

• log the CSP event to browser console
• send the relevant CSP report data to Telemetry service

With this PR, running Console and Bridge locally with dynamic demo plugin enabled should not trigger any CSP violations.

./bin/bridge -plugins console-demo-plugin=http://localhost:9001/ -i18n-namespaces=plugin__console-demo-plugin

Note 📝 since we use Content-Security-Policy-Report-Only instead of Content-Security-Policy header, the browser may warn about Console CSP not containing report-to (standard) or report-uri (deprecated) directives.

This is not an issue, since we use a custom CSP violation event handler to send the CSP report data where appropriate.

Note 📝 we don't use report-to or report-uri directives for the following reasons:

• it's less complex to send the CSP report data where appropriate directly from Console frontend
• Console frontend gives us full control over HTTP requests (i.e. adding security headers like CSRF token as necessary)

Follow-up work

Testing this PR has revealed that webpack generated Console assets require the following CSP exceptions:

• script-src 'unsafe-eval' triggered by unsafe JS code like eval()
• style-src 'unsafe-inline' triggered by inline <style> elements

These exceptions should be removed in the future.

cc @spadgett @jhadvig

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@vojtechszocs: This pull request references CONSOLE-4170 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the spike to target the "4.18.0" version, but no target version was set.

In response to this:

Summary

This PR adds initial Content Security Policy implementation for Console web application.

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft, to site defacement, to malware distribution.

Initially, we will deploy CSP in report-only mode via Content-Security-Policy-Report-Only HTTP header.

CSP violations are handled explicitly via Console SecurityPolicyViolationEvent handler, which does the following:

• log the CSP event to browser console
• send the relevant CSP report data to Telemetry service

With this PR, running Console and Bridge locally with dynamic demo plugin enabled should not trigger any CSP violations.

./bin/bridge -plugins console-demo-plugin=http://localhost:9001/ -i18n-namespaces=plugin__console-demo-plugin

Note 📝 since we use Content-Security-Policy-Report-Only instead of Content-Security-Policy header, the browser may warn about Console CSP not containing report-to (standard) or report-uri (deprecated) directives as shown in the following screenshot:

This warning is not an issue, since we use a custom CSP violation event handler. The "cannot report violations" part of this warning means the browser itself will not make any CSP related HTTP requests.

The error below the warning in the screenshot is due to Console HTML index template containing an inline script tag:

<script type="text/javascript">

This inline script tag is used to set up SERVER_FLAGS and theme config. The proper way to address this error is to allow this script tag - either generate a SHA hash representing its content or generate a cryptographically secure random token for the script.

Follow-up work

1. Address the above mentioned CSP inline script tag error.

2. Testing this PR has revealed that webpack generated Console assets require the following CSP exceptions, these should be removed in the future:

• script-src 'unsafe-eval' triggered by unsafe JS code like eval()
• style-src 'unsafe-inline' triggered by inline <style> elements

cc @spadgett @jhadvig

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@vojtechszocs: This pull request references CONSOLE-4170 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the spike to target the "4.18.0" version, but no target version was set.

In response to this:

Summary

This PR adds initial Content Security Policy implementation for Console web application.

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft, to site defacement, to malware distribution.

Initially, we will deploy CSP in report-only mode via Content-Security-Policy-Report-Only HTTP header.

CSP violations are handled explicitly via Console SecurityPolicyViolationEvent handler, which does the following:

• log the CSP event to browser console
• send the relevant CSP report data to Telemetry service

With this PR, running Console and Bridge locally with dynamic demo plugin enabled should not trigger any CSP violations.

./bin/bridge -plugins console-demo-plugin=http://localhost:9001/ -i18n-namespaces=plugin__console-demo-plugin

Note 📝 since we use Content-Security-Policy-Report-Only instead of Content-Security-Policy header, the browser may warn about Console CSP not containing report-to (standard) or report-uri (deprecated) directives as shown in the following screenshot:

This warning is not an issue, since we use a custom CSP violation event handler. The "cannot report violations" part of this warning means the browser itself will not make any CSP related HTTP requests.

The error below the warning in the screenshot is due to Console HTML index template containing an inline script tag used to set up SERVER_FLAGS and visual theme config. The proper way to address this error is to allow this script tag - either generate a SHA hash representing its contents or generate a cryptographically secure random token for the script.

Follow-up work

1. Address the above mentioned CSP inline script tag error.

2. Testing this PR has revealed that webpack generated Console assets require the following CSP exceptions, these should be removed in the future:

• script-src 'unsafe-eval' triggered by unsafe JS code like eval()
• style-src 'unsafe-inline' triggered by inline <style> elements

cc @spadgett @jhadvig

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[vojtechszocs]

/retest

[spadgett]

It would be good to have something in CI to report violations. If the Cypress tests can run today without violations, we could turn this on now to avoid regressions.

[spadgett]

I'd suggest we explore adding Cypress tests now if there are no known violations. Maybe there is something simple we can do to catch any CSP violation like we do for other generic runtime errors.

It looks like there are some special considerations for Cypress, though:

https://docs.cypress.io/guides/guides/content-security-policy

[reestr]

/label px-approved

[jhadvig]

@spadgett yes we discussed with @vojtechszocs that the CI implementation would be done as a followup, but probably we should first address the one violation console is currently triggering.
Edit:
Here is the story to track the CI part - https://issues.redhat.com/browse/CONSOLE-4279

[opayne1]

Just a couple docs nits but otherwise looks good to me! I'll go ahead and add the label.

/label docs-approved

[vojtechszocs]

Thanks @opayne1 for your review, PR updated.

[jhadvig]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jhadvig, vojtechszocs

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• frontend/OWNERS [jhadvig,vojtechszocs]
• pkg/OWNERS [jhadvig]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[yapei]

sorry, what does an empty data: schema mean here?

[vojtechszocs]

@yapei @jhadvig

This allows the web application to use data: URLs to embed certain content into the HTML markup.

In this case, we allow using data: URLs for img-src (images and favicons) and font-src (CSS fonts).

Using data: URLs is commonly used for web asset optimization. When building Console web application, the module bundler (webpack) may generate these data: URLs for any small-sized images and fonts.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/Sources#scheme-source

[jhadvig]

yes, this should be a valid value 👍

[yapei]

when dynamic plugin triggers CSP violation, we can only see warning message Content Security Policy violation detected

Content Security Policy violation seems to originate from plugin ${pluginName} doesn't print

[vojtechszocs]

@yapei @jhadvig

When detecting whether the CSP violation originates from a dynamic plugin or from Console application code itself, we look at blockedURI and sourceFile properties - if their values start with {consoleBaseURL}/api/plugins/ prefix, it means that the associated resource is fetched via Console Bridge server's plugin asset endpoint which allows us to infer the name of the dynamic plugin.

This is why the message is phrased "seems to originate from plugin" instead of just "originates from plugin". Any CSP violations which are due to {consoleBaseURL}/api/plugins/... requests are associated with dynamic plugins, but any dynamic plugin can also make requests to other (non-Console) endpoints.

If a plugin makes requests to non-Console endpoints (regardless of whether the requested service is inside or outside the cluster) it will trigger CSP violations which we have no way of associating with that dynamic plugin. These kind of CSP violations will be logged, but the "seems to originate from plugin" will not apply to them.

Each dynamic plugin team should test their own plugin on a cluster and ensure there are no CSP violations that may be traced back to their plugin.

In case a plugin really needs to make requests to non-Console endpoints then it should explicitly list such endpoints via ConsolePlugin custom resource (CONSOLE-4265).

[yapei]

Deployed our console-demo-plugin and tested, can see some CSP violation errors in browser console

Content-Security-Policy: (Report-Only policy) The page's settings would block a script (script-src-elem) at https://console.redhat.com/connections/cdn/next-integrations/actions/845/d41568b7f25714884231.js from being executed because it violates the following directive: "script-src 'self' 'unsafe-eval'"

Content-Security-Policy: (Report-Only policy) The page's settings would block the loading of a resource (connect-src) at https://console.redhat.com/connections/cdn/v1/projects/BnuS1RP39EmLQjP21ko67oDjhbl9zpNU/settings because it violates the following directive: "default-src 'self'" analytics.min.js:1:23752

Content-Security-Policy: (Report-Only policy) The page's settings would block the loading of a resource (connect-src) at https://api.segment.io/v1/m because it violates the following directive: "default-src 'self'"

[vojtechszocs]

@yapei @jhadvig

Deployed our console-demo-plugin and tested, can see some CSP violation errors in browser console

Content-Security-Policy: (Report-Only policy) The page's settings would block a script (script-src-elem) at https://console.redhat.com/connections/cdn/next-integrations/actions/845/d41568b7f25714884231.js from being executed because it violates the following directive: "script-src 'self' 'unsafe-eval'"

Content-Security-Policy: (Report-Only policy) The page's settings would block the loading of a resource (connect-src) at https://console.redhat.com/connections/cdn/v1/projects/BnuS1RP39EmLQjP21ko67oDjhbl9zpNU/settings because it violates the following directive: "default-src 'self'" analytics.min.js:1:23752

Content-Security-Policy: (Report-Only policy) The page's settings would block the loading of a resource (connect-src) at https://api.segment.io/v1/m because it violates the following directive: "default-src 'self'"

These CSP violations are not due to dynamic demo plugin - these are non-Console endpoints:

https://console.redhat.com/...
https://api.segment.io/...

As mentioned in my comment above, any requests to non-Console endpoints will trigger CSP violations according to the current Console policy.

We should determine whether ^^ endpoints are to be allowed on plugin level or on Console application level.

[jhadvig]

Yes, we need to determine where these endpoints are being called from and add them as en exception.
If its on the Console application level, we should extend the cspSources variable, or refactor the variable into a separate source based on the policy type.
If its on the plugin level, we will use the new API field.
Either way this can be done as follow up 👍

[vojtechszocs]

https://console.redhat.com/...
https://api.segment.io/...

These endpoints are used by the Console application, so we'll need a follow-up change to include them in cspSources when generating the Console CSP. In the meantime, we should treat these CSP violations as known issues that we plan to fix in the near future.

[yapei]

Thanks for detailed explanation @vojtechszocs
/label qe-approved

[openshift-ci-robot]

@vojtechszocs: This pull request references CONSOLE-4263 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.18.0" version, but no target version was set.

In response to this:

Summary

This PR adds initial Content Security Policy implementation for Console web application.

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft, to site defacement, to malware distribution.

Initially, we will deploy CSP in report-only mode via Content-Security-Policy-Report-Only HTTP header.

CSP violations are handled explicitly via Console SecurityPolicyViolationEvent handler, which does the following:

• log the CSP event to browser console
• send the relevant CSP report data to Telemetry service

With this PR, running Console and Bridge locally with dynamic demo plugin enabled should not trigger any CSP violations.

./bin/bridge -plugins console-demo-plugin=http://localhost:9001/ -i18n-namespaces=plugin__console-demo-plugin

Note 📝 since we use Content-Security-Policy-Report-Only instead of Content-Security-Policy header, the browser may warn about Console CSP not containing report-to (standard) or report-uri (deprecated) directives as shown in the following screenshot:

This warning is not an issue, since we use a custom CSP violation event handler. The "cannot report violations" part of this warning means the browser itself will not make any CSP related HTTP requests.

The error below the warning in the screenshot is due to Console HTML index template containing an inline script tag used to set up SERVER_FLAGS and visual theme config. The proper way to address this error is to allow this script tag - either generate a SHA hash representing its contents or generate a cryptographically secure random token for the script.

Follow-up work

1. Address the above mentioned CSP inline script tag error.

2. Testing this PR has revealed that webpack generated Console assets require the following CSP exceptions, these should be removed in the future:

• script-src 'unsafe-eval' triggered by unsafe JS code like eval()
• style-src 'unsafe-inline' triggered by inline <style> elements

cc @spadgett @jhadvig

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

/retest-required

Remaining retests: 0 against base HEAD 585e061 and 2 for PR HEAD f19c620 in total

[openshift-ci]

@vojtechszocs: all tests passed!

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.