SecureAuth breaks when I try to add new content-security-policy values

Version Affected:  All

Description:  

When adding certain CSP headers, they may interfere with a working SecureAuth realm.

Cause:  

Using a CSP like:

script-src 'strict-dynamic' 'nonce-r4nd0m' 'unsafe-inline' http: https:; object-src 'none'; base-uri 'none'; require-trusted-types-for 'script'; report-uri https://my.reporter.url

In the above, there are a couple of strict options and one secret added.

'strict-dynamic'

The script-dynamic allows you to simplify your CSP by favoring hashes and nonces. Since there are no hashes or nonces in the SecureAuth ASPX pages, enabling this option will break the SecureAuth pages on all new browsers. Configured correctly, it could work with older browser that do not support the strict-dynamic value.

'nonce-r4nd0m'

The nonce option could be used but is not used as this would require changing the SecureAuth web pages to include a nonce value for each script block in the code. Hotfixes could update files which would then remove the nonce value requiring another update to the updated files. It may not work for any dynamically generated scripts within the SecureAuth codebase and for this reason, it should not be used.

require-trusted-types-for 'script';

Disallows using strings with DOM XSS injection sink functions, and requires matching types created by Trusted Type policies. Please see CSP: Require-trusted-types-for - HTTP - W3cubDocs for details on usage and explanation.

Resolution:  

For the example given above, this is the best we can do to support the wanted content-security-policy:

script-src 'nonce-r4nd0m' 'unsafe-inline' http: https:; object-src 'none'; base-uri 'none'; report-uri https://my.reporter.url

Keep in mind, though, if you want the nonce to work properly, every ASPX page would need an update. Also, if nonce is used, not caching of pages will work, if IIS is configured to cache dynamic pages.

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.