[JIRA] (JENKINS-60865) Content Security Policy: smooth introduction

[wfollonier@cloudbees.com (JIRA)]

Wadeck Follonier created an issue

Jenkins / JENKINS-60865 Content Security Policy: smooth introduction Issue Type: Epic Assignee: Unassigned Components: core Created: 2020-01-25 11:30 Priority: Minor Reporter: Wadeck Follonier Objective of this Epic: introducing the Content Security Policy (reference). The advantage of that set of headers is to prevent a large number of XSS threats. The mechanism will prevent the execution of unauthorized scripts and styles. To achieve this migration with as little pain as possible, here are the proposed steps: 1) Moving inline scripts to their own file or equivalent 2) Moving inline styles to regular css class / file 3) Put in a place sort of a reporting / monitoring tooling inside Jenkins to know when a rule is broken 4) Once we are sufficiently confident we have covered all the cases, enforce the rules. The points 1 and 2 will already help in prevent "direct" XSS where variables are injected in the code directly. That will also clean up a bit the different (and weird) ways to inject variables into JavaScript / CSS. Add Comment

This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)

[wfollonier@cloudbees.com (JIRA)]

Wadeck Follonier updated an issue

Jenkins / JENKINS-60865 Content Security Policy: smooth introduction

Change By: Wadeck Follonier Objective of this Epic: introducing the Content Security Policy ([reference|https://developer.mozilla.org/fr/docs/Web/HTTP/CSP]). Without entering too much into details, to achieve a good CSP protection, we need to create a whitelist of URL that are approved (could be same-origin) for static content (CSS / JavaScript) or/and a list of whitelisted / authorized content. Adding a content (using its hash) to the whitelist has the drawback to add weight on every response.

The advantage of that set of headers is to prevent a large number of XSS threats. The mechanism will prevent the execution of unauthorized scripts and styles. To achieve this migration with as little pain as possible, here are the proposed steps: 1) Moving inline scripts to their own file or equivalent 2) Moving inline styles to regular css class / file 3) Put in a place sort of a reporting / monitoring tooling inside Jenkins to know when a rule is broken 4) Once we are sufficiently confident we have covered all the cases, enforce the rules. The points 1 and 2 will already help in prevent "direct" XSS where variables are injected in the code directly. That will also clean up a bit the different (and weird) ways to inject variables into JavaScript / CSS.

Add Comment

[wfollonier@cloudbees.com (JIRA)]

Wadeck Follonier updated an issue

Jenkins / JENKINS-60865 Content Security Policy: smooth introduction Change By: Wadeck Follonier

Objective of this Epic: introducing the Content Security Policy ([reference|https://developer.mozilla.org/fr/docs/Web/HTTP/CSP]). Without entering too much into details, to achieve a good CSP protection, we need to create a whitelist of URL that are approved (could be same-origin) for static content (CSS / JavaScript) or/and a list of whitelisted / authorized content. Adding a content (using its hash) to the whitelist has the drawback to add weight on every response. The advantage of that set of headers is to prevent a large number of XSS threats. The mechanism will prevent the execution of unauthorized scripts and styles. To achieve this migration with as little pain as possible, here are the proposed steps:

1) Moving inline scripts / styles to their own file or equivalent 2) Moving inline styles to regular css class / file 3) Put in a place sort of a reporting / monitoring tooling inside Jenkins to know when a rule is broken 4 3 ) Once we are sufficiently confident we have covered all the cases, enforce the rules.

The points 1 and 2 will already help in prevent "direct" XSS where variables are injected in the code directly. That will also clean up a bit the different (and weird) ways to inject variables into JavaScript / CSS.

Add Comment

[ian.williams1@telus.com (JIRA)]

Ian Williams commented on JENKINS-60865

Re: Content Security Policy: smooth introduction I'm not sure this is the best place to ask, but it seems to be a question worth considering in context  ... There are a number of plugins which do not work properly as a result of the (now) default CSP restrictions. Some of this is documented in the wiki (Maven integration, javadoc, HTML Publisher). Others are referenced in the Comments (Gatling, OWASP, PHP Code Coverage). I know of others from personal experience (Robot Framework) and there are plenty of questions on StackOverflow I don't know that I can trust much of the guidance or generalize form it. The most common piece of advise is simply to turn off the security, which is very risky. Some experimentation shows a more granular relaxation of rules also results in a functional plugin. What would really help though is the requirement in the plug-in documentation that, IF the default CSP settings breaks the plug-in functionality, the plug-in provider must provide the appropriate documentation of which minimal settings must be relaxed to restore functionality.

Add Comment

[ian.williams1@telus.com (JIRA)]

Ian Williams edited a comment on JENKINS-60865

Re: Content Security Policy: smooth introduction

I'm not sure this is the best place to ask, but it seems to be a question worth considering in context  ... There are a number of plugins which do not work properly as a result of the (now) default CSP restrictions.

Some of this is documented in the [wiki (Maven integration, javadoc, HTML Publisher)|https://wiki.jenkins.io/display/JENKINS/Configuring+Content+Security+Policy]. Others are referenced in the Comments (Gatling, OWASP, PHP Code Coverage). I know of others from personal experience (Robot Framework) and there are plenty of [questions on StackOverflow|https://stackoverflow.com/search?q=%5Bjenkins%5D+%22Dhudson.model.DirectoryBrowserSupport.CSP%22] I don't know that I can trust much of the guidance or generalize form from it. The most common piece of advise advice is simply to turn off the security, which is very risky. Some experimentation shows a more granular relaxation of rules also results in a functional plugin.

What would really help though is the requirement in the plug-in documentation that, IF the default CSP settings breaks the plug-in functionality, the plug-in provider must provide the appropriate documentation of which minimal settings must be relaxed to restore functionality.

Add Comment

[wfollonier@cloudbees.com (JIRA)]

Wadeck Follonier commented on JENKINS-60865

Re: Content Security Policy: smooth introduction

Ian Williams The CSP restriction you are talking about are only for the DirectoryBrowser stuff and it was "solved" by the introduction of the ResourceDomain feature. References: https://wiki.jenkins.io/display/JENKINS/Configuring+Content+Security+Policy "Alternatives" https://issues.jenkins-ci.org/browse/JENKINS-41891 and its PR: https://github.com/jenkinsci/jenkins/pull/4239 The most common piece of advice is simply to turn off the security No longer the case with the resource domain This Epic is more about "CSP everywhere". But I really understand your fear here, especially with all the plugin (1600+) we have to care about. It's the reason of the step 2 in the proposal. In a proprietary software, the step 2 would not have been required.

Add Comment

[wfollonier@cloudbees.com (JIRA)]

Wadeck Follonier edited a comment on JENKINS-60865

Re: Content Security Policy: smooth introduction

[~ianw] The CSP restriction restrictions you are talking about are only for the DirectoryBrowser stuff and it was "solved" by the introduction of the ResourceDomain feature. References: - https://wiki.jenkins.io/display/JENKINS/Configuring+Content+Security+Policy "Alternatives" - https://issues.jenkins-ci.org/browse/JENKINS-41891 and its PR: https://github.com/jenkinsci/jenkins/pull/4239 bq. The most common piece of advice is simply to turn off the security No longer the case with the resource domain :)

This Epic is more about "CSP everywhere". But I really understand your fear here, especially with all the plugin (1600+) we have to care about. It's the reason of the step 2 in the proposal. In a proprietary software, the step 2 would not have been required.

Add Comment

[wfollonier@cloudbees.com (JIRA)]

Wadeck Follonier edited a comment on JENKINS-60865

Re: Content Security Policy: smooth introduction

[~ianw] The CSP restrictions you are talking about are only for the DirectoryBrowser stuff and it was "solved" by the introduction of the ResourceDomain feature.

References: - https://wiki.jenkins.io/display/JENKINS/Configuring+Content+Security+Policy "Alternatives" - https://issues.jenkins-ci.org/browse/JENKINS-41891 and its PR: https://github.com/jenkinsci/jenkins/pull/4239 bq. The most common piece of advice is simply to turn off the security No longer the case with the resource domain :)

(and IIRC there is an admin monitor activated if you disabled the CSP, proposing to move to second domain)

This Epic is more about "CSP everywhere". But I really understand your fear here, especially with all the plugin (1600+) we have to care about. It's the reason of the step 2 in the proposal. In a proprietary software, the step 2 would not have been required.

Add Comment

[ian.williams1@telus.com (JIRA)]

Ian Williams commented on JENKINS-60865

Re: Content Security Policy: smooth introduction

Wadeck Follonier Thank you for the prompt response. We are just about to start planning to upgrade 2.204 LTS, so was not aware /JENKINS-41891 was Fixed. We will review this impact. I look forward to how the reporting tool will work and what kind of communication there will be back to plug-in providers so as to rehabilitate their plug-ins or provide better user guidance and action where necessary if issues remain.

Add Comment

[wfollonier@cloudbees.com (JIRA)]

Wadeck Follonier commented on JENKINS-60865

Re: Content Security Policy: smooth introduction

I look forward to how the reporting tool will work and what kind of communication there will be back to plug-in providers so as to rehabilitate their plug-ins or provide better user guidance and action where necessary if issues remain. It will be a public effort so any feedback will be more than appreciated Not only from a maintainer PoV but also for the admin/user's one

Add Comment