[keycloak-dev] Improved CSP support

[Stian Thorgersen]

Not sure if it's an option to remove all inline scripts/styles. Maybe it is.

With regards to the other options. SHA hash seems rather brittle and hard
to maintain, so a nonce would probably be the better option. I haven't
looked to much at the details on how that's handled, but I assume it's a
per-request so you can easily generate one in
FreeMarkerLoginProvider/AccountProvider, add it to the header, then
templates can themselves add the nonce using something like
none="${cspNonce}".

Seems like an elegant solution to something we're working on at the moment.
Currently most fields are escaped so it's not possible to for example
inject scripts, but there are some that are not as they need to output HTML
tags (realm display name for instance). We've ended up with using OWASP
HTML sanitizer library to escape unsafe elements. It's a bit messy code +
we need to productize the OWASP library. It sounds like this could remove
the need to do that altogether.

On Wed, 20 Jun 2018 at 00:30, Johannes Knutsen <johannes at kodet.no> wrote:

> Hi,
>
> I am currently looking at improvements in the Content Security Policy
> (CSP) support.
>
> In our deployment, we have security requirements stating that a CSP
> header should be used and inline scripts, styles and resources should
> be blocked. For example by setting a CSP value like default-src
> 'self';.
>
> Such a policy breaks Keycloak's manipulation of the browser history
> implemented in the BrowserHistoryHelper, since the
> JavascriptHistoryReplace injects an inline JavaScript.
>
> The simplest workaround is to also inject a nonce value or SHA hash of
> the script to the existing CSP header.
>
> However, while implementing this, I found that a CSP nonce in general
> would be nice to have available in any template context. This will
> also make it easier to migrate the default Keycloak theme to support
> stricter security policies.
>
> An example implementation can be found here:
>
> https://github.com/knutz3n/keycloak/commit/c6cfb3efa2942d7569066c0e4bd90a2ed75a0005
>
> Would you be interested in merging a change like the one above? If
> not, what is your view on how to allow stricter content security
> policies?
> Tests and documentation is currently missing, but I will add both if
> this is something you would consider merging.
>
> As a note, I have also done some work on supporting a strict CSP value
> for the default theme. But there are some issues with included 3rd
> party scripts which must/should be resolved. Let me know if you want
> more details regarding this.
>
> Best regards,
> Johannes Knutsen
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>