Introduce Content Security Policy

Summary

GoCD does not currently have a universal CSP across the web pages; which poses a security risk if there are any XSS style vulnerabilities.

Motivation / Use Case

Due to the way GoCD does various types of HTML rendering, there is some risk of XSS in various places (m.trust within the frontend, direct HTML rendering on backend, etc). Such vulnerabilities will typically allow the credentials of attacked users to be exfiltrated without a CSP to mitigate this.

It would somewhat mitigate the impact of doing so to have a CSP, at least with connect-src, img-src restrictions etc, even if inline scripting cannot be disabled.

It's worth noting that on the typical attack vector (low privilege authenticated user attaching a privileged user) it wouldn't entirely mitigate such issues; however because generally if one has an existing "read" account, one could often make the attacked user post the "to be exfiltrated" credentials via GoCD's API to a location that the attacker can read. It would just make it more difficult, and harder to hide ones tracks.

Proposal

Start with a basic policy applied as widely as possible across browser-rendered pages (Spring + Rails assets), with some ability to customise it.

Many challenges, but possibly include

• rendering of artifacts inside jobs/builds may require more lenient permissions, for images/fonts at least
• iframes for stage graphs
• plugin view rendering