Remove inline styles and scripts for better Jenkins CSP compliance

[medianick]

Jenkins 1.641 / Jenkins 1.625.3 LTS introduced a new Content Security Policy with a very restrictive default (described at https://wiki.jenkins-ci.org/display/JENKINS/Configuring+Content+Security+Policy#ConfiguringContentSecurityPolicy-Implementation). This breaks the coverage reports generated by ReportGenerator in several ways. Adjusting Jenkins' CSP to allow ReportGenerator's "combined.js" file might be reasonable (via script-src 'self'), but allowing the inline JavaScript and inline style attributes (via script-src 'unsafe-inline' and style-src 'unsafe-inline') that ReportGenerator uses would open too much of a gap in the intended CSP security model.

Could you move the (generated) inline JavaScript into a separate .js file, and define the % widths as classes in a separate stylesheet file (or set the style attributes in a function in the .js file), so that no inline scripts or styles are needed?

[danielpalme]

I will have a look at this. But it may take some time

[medianick]

Thanks! For what it's worth, I had to set a variety of CSP settings to allow Jenkins to display ReportGenerator content properly:

sandbox allow-scripts; default-src 'none'; img-src 'self' data:; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' 'unsafe-eval'

The data: URL was to handle inline base64 images, the 'unsafe-inline' for styles was to handle the style attributes (style="width:92px", etc.), the 'unsafe-inline' for scripts was to handle the inline JavaScript, and the 'unsafe-eval' was to handle the use of Function() calls.

[danielpalme]

I took a quick look. Jenkins is very restrictive.
Some of my inline styles could be easily replaced by CSS classes (I don't understand why this should be safer....). But for example the red/green bar which indicates coverage is rendered with inline styles. I don't want to render this with JavaScript, this would break clients with JavaScript disabled.
I'm not sure what to do here.

[medianick]

Yeah, defining 100 different CSS classes for 1-100px widths does seem unappealing, although that does seem to be the only non-JS way to get around an inline style prohibition. Some more info on the dangers of inline styles is here: http://stackoverflow.com/a/31759553/466874.

[danielpalme]

I started working on this issue. I think I can provide a new release in the next days.

[medianick]

Thanks Daniel. I really appreciate it.

[danielpalme]

Could you please test this release: https://www.nuget.org/packages/ReportGenerator/2.4.0-beta2
I removed all inline styles and scripts.

With the default Jenkins settings ("sandbox; default-src 'self';") you should see a correctly formatted static report.

If you enable scripts with the following command, all dynamic features should work:

System.setProperty("hudson.model.DirectoryBrowserSupport.CSP", "sandbox allow-scripts; default-src 'self';")

Let me know if something is not working yet.

[medianick]

I just tested it after resetting the Jenkins CSP to its default, and the report renders correctly as a static document (with green/red bars of the proper widths). I then adjusted the CSP to the setting you'd suggested, and it rendered properly with all the usual dynamic controls (expand/collapse and the Grouping slider). It works perfectly. Thank you!

[danielpalme]

Great. Thanks for your input and help.