Saml2: Content Security Policy (CSP) support

[jaydinslage]

When HTTP posting to the SAML IDP, the HTML is generated by a constant in the code and returned to the browser. The javascript in this HTML is inline and requires the CSP to have 'unsafe-inline' enabled. This is a security concern. It would be nice to at least specify a nonce for the script or to allow the script to be in a separate javascript file.

[AndersAbel]

Interesting issue. CSP wasn't even thought of when the SAML2 standard was written... and not anything in widespread use when I started the development of this library.

The HTML used is actually outlined in the SAML2 binding spec. It also states that it must be valid XHTML.

The HTML document MUST adhere to the XHTML specification

Do you have any idea how to rework this to play nicely with CSP? And I guess this means that some more headers should be added to the response as well? Using a nonce sounds like the best option to me as that would still allow the script to be kept in the same response.

[fuzzzerd]

For inline scripts; its possible to provide a hash so that they are not required to be unsafe-inline: see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src#Sources. As long as the script is not dynamic it should be possible to compute the hash ahead of time and include it in the script tag.

[AndersAbel]

A hash looks easiest. The script is fixed, so a hash can be calculated once and stored as a constant in the code. A nonce would also be doable, but would require a new number every time.

[jaydinslage]

I'm cool with either. Our code automatically adds the CSP header to all responses. I have special code that adds 'unsafe-inline' to only this page.

[LeanderVanEck]

The meta tag for the content-security-policy seems to create a problem on the Safari browser in case the response headers also contain a content-security-policy header that includes a script-src and/or a default-src. In that case the browser is blocking the script from executing.

Is this a known issue? If not, should we create a new issue for this?
Perhaps there should be an option to exclude the meta-tag.

[explunit]

@LeanderVanEck I've not heard of that problem before. Yes, new issue with details of any Safari console errors would be good.

[fuzzzerd]

The CSP meta tag will not allow you to make loosen security specified in a CSP header. You would need to add that script hash to your CSP header explicitly.

[LeanderVanEck]

The CSP meta tag will not allow you to make loosen security specified in a CSP header. You would need to add that script hash to your CSP header explicitly.

It's not our intention to loosen the security provided by the meta-tag. We just did not expect the script to no longer be able to execute when the response includes the CSP header. In other browsers (Edge / IE / Chrome) this works without any problems, but in Safari it blocks execution. Console reports the following error:

'Refused to execute a script because its hash, its nonce, or 'unsafe-inline' does not appear in the script-src directive of the Content Security Policy.'

We are using 'unsafe-inline' inside the script-src directive. So it seems Safari is not correctly applying either the meta-tag or the CSP header.

Adding the hash to the header script-src directive does seem to work fine. But there isn't any guarantee that this hash value won't change in any future release.