Recently I have been involved at a customer where we did the NetScaler Gateway implementation. Our good practise is to make sure that we lease the internet accessible IP’s with atleast an A rating in SSL Labs.
At the customer I was involved a Pentest was conducted. The pentest was pretty thourough (as expected) and came with a few recommandations. A few of the recommandations related to the HTTP header the NetScaler sends back. This article describes the headers and how to modify this with NetScaler.
Content Security Policy
Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.
How to solve this:
add rewrite action rw_act_insert_CSP_header insert_http_header Content-Security-Policy “"default-src 'self' ; img-src 'self' 'data' ; connect-src 'self' 'wss' ; report-uri https://report-uri.io/report/URL;"”
add rewrite policy rw_pol_enforce_CSP TRUE rw_act_insert_CSP_header
Public key pinning
HTTP Public Key Pinning, or HPKP, is a security policy delivered via a HTTP response header much like HSTS and CSP. It allows a host to provide information to a user agent about which cryptographic identities it should accept from the host in the future. This can protect a host website from a security compromise at a Certificate Authority where rogue certificates may be issued for your hostname.
How to solve this:
add rewrite action rw-act-PublicKeyPin insert_http_header Public-Key-Pins q{“pin-sha256=""; pin-sha256=""; max-age=2592000; includeSubDomains”}
add rewrite policy rw-pol-publickeypin true rw-act-PublicKeyPin
X-XSS-Protection
This header is used to configure the built in reflective XSS protection found in Internet Explorer, Chrome and Safari (Webkit). Valid settings for the header are 0, which disables the protection, 1 which enables the protection and 1; mode=block which tells the browser to block the response if it detects an attack rather than sanitising the script.
How to solve this
add rewrite action rw-act-insert-XSS-header insert_http_header X-Xss-Protection “"1; mode=block"”
add rewrite policy rw-pol-enforce-XSS TRUE rw-act-insert-XSS-header
X-Content-Type-Options#
Nice and easy to configure, this header only has one valid value, nosniff. It prevents Google Chrome and Internet Explorer from trying to mime-sniff the content-type of a response away from the one being declared by the server. It reduces exposure to drive-by downloads and the risks of user uploaded content that, with clever naming, could be treated as a different content-type, like an executable.
How to solve this:
add rewrite action rw-act-insert-XContent_header insert_http_header X-Content-Type-Options “"nosniff"”
add rewrite policy rw-pol-enforce-XContent TRUE rw-act-insert-XContent_header
Now that all policies and actions are in place we need to bind them to the vServer. Bind them as rewrite/response policy and use the goto expression of next, to make the policy processing continue after applying.
After applying the policies, head over to securityheaders.io hit the URL of your website and see the results:
