-
Epic
-
Resolution: Unresolved
-
Minor
-
None
-
CSP compatibility for Jenkins plugins
-
Full details on the approach: https://docs.google.com/document/d/1hr_Kaf0fVWBACibpHbSYsk4RoqcHD3cBrqXxuTtWKVM (public)
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) Put in a place sort of a reporting / monitoring tooling inside Jenkins to know when a rule is broken
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.
Compatibility for plugins
https://docs.google.com/spreadsheets/d/1Jr5FpkAN-FjTd0D_VLz00Ab5iXNiCK03fUs2JR2omXQ
Documentation on jenkins.io about how to find and adjust code
https://www.jenkins.io/doc/developer/security/csp/
- depends on
-
JENKINS-71014 CSP compatibility for Jenkins core
- Open
- links to
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 from it. The most common piece of 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.