I was recently asked to troubleshoot an issue where an administrator implemented the Content-Security-Policy HTTP Response Header on a Citrix ADC for Citrix Apps and Desktops with DUO integration and immediately noticed that users were no longer able to successfully log onto the portal. The following outlines the behavior and steps to remediate the issue.
**Note that more information about the Content Security Policy HTTP response header can be found in Scott Helme’s article at the following URL: https://scotthelme.co.uk/content-security-policy-an-introduction/
Problem
The following Rewrite, Policy and Binding was configured onto the Citrix ADC (formerly known as Citrix ADC) to secure the
add rewrite action rw_act_insert_Content_security_policy insert_http_header Content-Security-Policy “”default-src ‘self’ ; script-src ‘self’ ‘unsafe-inline’ ‘unsafe-eval’ ; style-src ‘self’ ‘unsafe-inline’ ‘unsafe-eval’; img-src ‘self’ data:””
add rewrite policy rw_pol_insert_Content_security_policy “HTTP.RES.HEADER(“Content-Security-Policy”).EXISTS.NOT” rw_act_insert_Content_security_policy
bind vpn vserver _XD_10.0.1.11_443 -policy rw_pol_insert_Content_security_policy -type RESPONSE -priority 160
The login page presented by the Citrix ADC displays and functions properly:
However, the 2FA authentication page that is supposed to present the DUO multifaction options for sending the user a push, call to their mobile or entering a password does not load as the redirect appears to fail:
Solution
The best way to troubleshoot such an issue when implementing the Content-Security-Policy HTTP Response Header on Citrix ADC is to switch the rewrite action to insert a Content-Security-Policy-Report-Only header instead of the Content-Security-Policy header as this would simply report the expected action and results rather than enforce them. To enable this feature, simply change the field from Content-Security-Policy to Content-Security-Policy-Report-Only as shown in the following screenshot:
With the reporting mode enabled, proceed to relaunch the Google Chrome browser, click on the horizontal ellipsis from the top right corner, select More Tools, then Developer tools (CTRL+SHIFT+I):
With the Developer tools window opened, select the Network tab, click on the ellipsis at the top right corner and select Show console drawer:
The Network tab will display all the resources that is loaded as you navigate through the portal and the console will output verbose details of the Content Security Policy being applied but will only report the results rather than enforce it. Note the output shown in the console:
The Content Security Policy ‘default-src ‘self’ ; script-src ‘self’ ‘unsafe-inline’ ‘unsafe-eval’ ; style-src ‘self’ ‘unsafe-inline’ ‘unsafe-eval’; img-src ‘self’ data:’ was delivered in report-only mode, but does not specify a ‘report-uri’; the policy will have no effect. Please either add a ‘report-uri’ directive, or deliver the policy via the ‘Content-Security-Policy’ header.
Proceed to log into the portal to replicate the issue, and in the case of this example, the console will display the following output indicating why the DUO authentication webpage would have been blocked:
[Report Only] Refused to load the script ‘https://api-01b56e27.duosecurity.com/frame/hosted/Duo-Citrix-NetScaler-RfWebUI-v1.js’ because it violates the following Content Security Policy directive: “script-src ‘self’ ‘unsafe-inline’ ‘unsafe-eval’ “. Note that ‘script-src-elem’ was not explicitly set, so ‘script-src’ is used as a fallback.
[Report Only] Refused to frame ‘https://api-01b56e27.duosecurity.com/’ because it violates the following Content Security Policy directive: “default-src ‘self'”. Note that ‘frame-src’ was not explicitly set, so ‘default-src’ is used as a fallback.
The report from above indicate the following directives we defined in our rewrite action are preventing the redirect of the DUO 2FA api-01b56e27.duosecurity.com page from being loaded:
“default-src ‘self’ ; script-src ‘self’ ‘unsafe-inline’ ‘unsafe-eval’ ; style-src ‘self’ ‘unsafe-inline’ ‘unsafe-eval’; img-src ‘self’ data:”
To remediate the issue, simply modify the rewrite action as such to include the subdomains of the page the portal is attempting to redirect the user:
“default-src ‘self’ *.duosecurity.com ; script-src ‘self’ *.duosecurity.com ‘unsafe-inline’ ‘unsafe-eval’ ; style-src ‘self’ ‘unsafe-inline’ ‘unsafe-eval’; img-src ‘self’ data:”
Note that I opted to include all of the subdomains because I am unsure as to whether DUO would ever change the URL in the future but in the event where you are certain this URL will not change, it would be best to specify an exact match.
————————————————————————————————————————–
Update: April 26, 2020
As I wasn’t familiar with Duo deployments and had only recently been able to deploy the solution, I had that the hostname api-01b56e27.duosecurity.com is unique to the application Duo is protecting so the URL isn’t supposed to change as long as you do not remove and recreate the application in the Duo administration console. You can retrieve the URL in the Duo administration console shown in this screenshot:
————————————————————————————————————————–
With the changes made, proceed to relaunch the page to verify that the authentication page is no longer blocked and loads successfully:
… then change the Header Name for the rewrite action on the Citrix ADC from Content-Security-Policy-Report-Only back to Content-Security-Policy.
I hope this will help anyone who may experience a similar issue when securing their web applications to score an A at: https://securityheaders.com/
