On Mon, 30 Jul 2018 at 20:19, Johannes Knutsen <johannes(a)kodet.no> wrote:
Actually, your suggestion to inject a cspNonce value through the
FreeMarkerLoginProvder/AccountProvider is the exact solution I chose
to implement in the example implementation,
Sounds good, I'm leaving for holiday today so won't have time to take a
look at it before I'm back in a week or so.
CSP support in the admin GUI, seems to be a hard problem. I did some
work to get this working and most issues were resolveable. However,
the ACE editor has an open issue,
, regarding CSP and there
was also a minor change required to ng-file-upload.
Is it only the ACE editor that is an issue? If that remains an issue we
could consider removing it. It's only used when editing js authenticators
and policies, but I don't think it's all that useful afaik.
Our first priority is anyways to be able to disable inline scripts on
our customer's authentication realm and currently we get a CSP error
when setting a script-src 'self' rule:
"Refused to execute inline script because it violates the following
Content Security Policy directive: "script-src 'self'". Either the
'unsafe-inline' keyword, a hash ('sha256-h/...'), or a nonce
('nonce-...') is required to enable inline execution."
This is due to the inline script injected by BrowserHistoryHelper.java
and adding a CSP nonce solves this.
Do you generate the nonce on demand in your branch? As it's only needed for
very few requests we should generate one in the FreeMarker providers unless
it's actually needed.
I don't think CSP should replace using a sanitizer, since CSP support
is varying between browsers. However, if you would consider merging
the addition of adding a CSP nonce value to the Freemarker context as
shown in the diff above, I would be happy to add some tests. At least
it would allow template developers to also use inline scripts, by
using the CSP nonce value as you mentioned.
We'll keep the sanitizer as well. Always good to have more layers of
defence than less ;)
Would be ideal to have a complete solution. Nonce available, updated
default value for CSP header for realms, including migrating existing
realms when the value hasn't changed.
On Mon, Jul 30, 2018 at 7:48 PM, Stian Thorgersen <sthorger(a)redhat.com>
> Not sure if it's an option to remove all inline scripts/styles. Maybe it
> With regards to the other options. SHA hash seems rather brittle and
> maintain, so a nonce would probably be the better option. I haven't
> 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
> Seems like an elegant solution to something we're working on at the
> Currently most fields are escaped so it's not possible to for example
> 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
> to productize the OWASP library. It sounds like this could remove the
> to do that altogether.
> On Wed, 20 Jun 2018 at 00:30, Johannes Knutsen <johannes(a)kodet.no>
>> 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
>> Such a policy breaks Keycloak's manipulation of the browser history
>> implemented in the BrowserHistoryHelper, since the
>> 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:
>> 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
>> 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