Version Affected: All
Overview
Adding certain Content-Security-Policy (CSP) header values can interfere with a working SecureAuth realm and break its ASPX pages.
Cause
For example, a CSP like the following breaks SecureAuth pages on modern browsers:
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.urlThis example uses several strict options that don't work with SecureAuth's own pages:
- strict-dynamic simplifies a CSP by favoring hashes and nonces over broader source lists. SecureAuth's ASPX pages don't include any hashes or nonces, so enabling this option breaks them on any modern browser that enforces it. On an older browser that doesn't support strict-dynamic, it can work if configured correctly.
- nonce-r4nd0m (or any nonce value) isn't usable, because it would require every script block in every SecureAuth ASPX page to include a matching nonce. A hotfix can update a file and remove that nonce value, requiring another update to add it back, and dynamically generated scripts in the SecureAuth codebase may not get a nonce at all.
- require-trusted-types-for 'script' disallows using strings with DOM XSS injection sink functions, and requires matching types created by Trusted Type policies — SecureAuth's pages are not written to satisfy this requirement.
Resolution
For the example above, the closest CSP that still supports SecureAuth's pages is:
script-src 'nonce-r4nd0m' 'unsafe-inline' http: https:; object-src 'none'; base-uri 'none'; report-uri https://my.reporter.urlRemove strict-dynamic and require-trusted-types-for 'script' from the policy, and drop the nonce value if it isn't actually being added to SecureAuth's own script blocks.
Special Considerations
If you do keep a nonce value in the policy, every ASPX page would need to be updated to include it, and IIS dynamic-page caching cannot be used at the same time as a nonce-based CSP.
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.
Comments
Please sign in to leave a comment.