“Q11827 HTTP Security Header Not Detected” on NetScaler Management IP Using Qualys Scan


1. This is a generic template that is applicable across various NS Versions, some of these may not be needed on later versions, for version specific config, please review fiddler / dev-tool output while accessing NetScaler Management IP and apply the config in part two for the missing headers only.

2. Take System backup before making any changes

3. Check GUI Access, API Based monitoring tools functionality (NMAS, Command Center, any other) with NetScaler thoroughly after making these changes

Part 1: Execute following command on Shell prompt to enable rewrite feature on Management IP, and to make the changes persistent across reboot (On both Primary and Secondary)

nsapimgr_wr.sh -ys skip_systemaccess_policyeval=0

cd /nsconfig

echo nsapimgr_wr.sh -ys skip_systemaccess_policyeval=0 >> rc.netscaler

cat rc.netscaler | grep skip_systemaccess

Part 2: Exit from Shell and execute the following commands on > prompt (On primary only, these commands with sync on secondary)

Enable ns feature rewrite

add policy expression is_management_ip client.ip.dst.eq(SYS.NSIP)

add rewrite action insert_x-xss-protection_act insert_http_header X-XSS-Protection “”1; mode=block””

add rewrite action insert_x-content-type-options_act insert_http_header X-Content-Type-Options “”nosniff””

add rewrite action insert_x-frame-options_act insert_http_header X-Frame-Options “”SAMEORIGIN””

add rewrite action insert_x-hsts-header_act insert_http_header Strict-Transport-Security “”max-age=157680000; includeSubDomains””

add rewrite action insert_CSP_act insert_http_header Content-Security-Policy “”frame-ancestors ‘self'””

add rewrite policy insert_x-xss-protection_pol “is_management_ip && http.RES.HEADER(“X-XSS-Protection”).EXISTS.NOT” insert_x-xss-protection_act

add rewrite policy insert_x-content-type-options_pol “is_management_ip && http.RES.HEADER(“X-Content-Type-Options”).EXISTS.NOT” insert_x-content-type-options_act

add rewrite policy insert_x-frame-options_pol “is_management_ip && http.RES.HEADER(“X-Frame-Options”).EXISTS.NOT” insert_x-frame-options_act

add rewrite policy insert_x-hsts-header_pol “is_management_ip && http.RES.HEADER(“Strict-Transport-Security”).EXISTS.NOT” insert_x-hsts-header_act

add rewrite policy insert_CSP_pol “is_management_ip && http.RES.HEADER(“Content-Security-Policy”).EXISTS.NOT” insert_CSP_act

#Note: The priority Nos below may have to be edited to not conflict with existing globally bound policies

bind rewrite global insert_x-xss-protection_pol 2 next -type RES_DEFAULT

bind rewrite global insert_x-content-type-options_pol 3 next -type RES_DEFAULT

bind rewrite global insert_x-frame-options_pol 4 next -type RES_DEFAULT

bind rewrite global insert_CSP_pol 5 next -type RES_DEFAULT

bind rewrite global insert_x-hsts-header_pol 6 next -type RES_DEFAULT


  • No Related Posts

How Do I Configure HTTP Strict Transport Security (HSTS) on NetScaler

HSTS stands for HTTP Strict Transport Security. The main objective of HSTS is to protect websites against various attacks like SSL strip, Cookie Hijacking, Downgrade attack etc. RFC 6797 covers the exact IETF standardized functionality of HSTS. HSTS enables servers to declare to other entities (Web browsers, Applications etc) to communicate to the server only via HTTPS connection. This is done by web server by setting Strict-Transport-Security HTTP response header field.

NetScaler 12.0 appliances support HTTP strict transport security (HSTS) as an inbuilt option in SSL profiles and SSL virtual servers. For information on configuring this feature refer to CTX224172 – How to Enable HTTP Strict Transport Security (HSTS) on NetScaler 12.

Use Case

  • Ramesh wishes to interact with various web sites (some arbitrary, some known) in a secure fashion through a web browser.

  • Banking.com wishes to offer their site in an explicitly secure fashion for their own, as well as their users’, benefit.

Ramesh has user account in banking.com and is a regular user transacting through banking.com regularly. As usual Ramesh wants to transfer money to his friend and thus he accesses the website banking.com by typing URL www.banking.com.

User-added image

In this case, browser converts this to http://www.banking.com. Browser detects the name banking.com, communicates with DNS server and gets IP address for host server.

Browser contact the IP address received on port 80. The banking website sends a redirect request to https://www.banking.com. SSL handshake and certificate verification happens leading to SSL connection establishment. The padlock in URL bar will change to green and will be in locked state.

User-added image

User-added image
Ramesh can now enter his credentials safely to make the required transaction.

Well, what can go wrong now? A man in the middle can intercept the resolving request for banking.com and send Ramesh his own server ip address. When request is made to the IP address on port 80 he can redirect Ramesh to his own slightly mispronounced website https://www.blanking.com. Ramesh might not notice the change and enter his credentials thereby giving his details to someone else.

Other possibility is when intruder presents his own certificate for banking.com and this time browser identifies it is not a trusted certificate and sends a pop up asking Ramesh if he wants to override this warning. People , at times ignore warning messages and will end up falling in the trap of intruder.

How HSTS helps?

HSTS sends Strict-Transport-Security flag set in the HTTP response header field. It also sends a value in the header which denotes the time for which the browser can keep the website under STS sites.

HSTS prevents scenarios mentioned above by making sure that they respond only to https request and doesn’t allow Ramesh to override the warning. Also in recent browser versions when the browser receives a HTTP request for a website under STS list, it will automatically makes a HTTPS request to the server thus helping users to be protected from these attacks. This cool feature can be enabled in NetScaler enabling actual backend servers to have this protection through NetScaler path as we do SSL offloading on NetScaler.


  • No Related Posts

How to Enable HTTP Strict Transport Security (HSTS) on NetScaler 12

This article describes how to enable HTTP Strict Transport Security (HSTS) on NetScaler 12.

If you would like to configure HSTS on NetScaler version older than 12 then refer to CTX205221 – How Do I Configure HTTP Strict Transport Security (HSTS) on NetScaler.


NetScaler 12.0 appliances support HTTP strict transport security (HSTS) as an inbuilt option in SSL profiles and SSL virtual servers. Using HSTS, a server can enforce the use of an HTTPS connection for all communication with a client. That is, the site can be accessed only by using HTTPS. Support for HSTS is required for A+ certification from SSL Labs.

You can enable HSTS in an SSL front-end profile or on an SSL virtual server. If you enable SSL profiles, then you should enable HSTS on an SSL profile instead of enabling it on an SSL virtual server. By setting the maximum age header, you specify that HSTS is in force for that duration for that client. You can also specify whether subdomains should be included. For example, you can specify that subdomains for www.example.com, such as www.abc.example.com and www.xyx.example.com, can be accessed only by using HTTPS by setting the IncludeSubdomains parameter to YES.


  • No Related Posts

Scanning tool reported XML management interface port 5550 violating CWE-693. How to fix it?

Scanning tool reports XML management interface port 5550 violating CWE-693 and suggest to setup proper X-Frame-Options, X-XSS-Protection, Content Security Policy, X-Content-Type-Options and Strict-Transport-Security HTTP response headers as protection mechanism.
How to fix CWE-693? And is it possible to setup those headers?


  • No Related Posts

Page is not available after HSTS is enabled

First redirection from 8080 to 443 works as expected with 302 response from NetScaler. Consecutive attempts give 301 redirection code from 8080 to 8080

RFC 6797 section 8.3, once HSTS is set for a Domain the Browser, not the NetScaler, will redirect the request before the load of the page to HTTPS.

if the URI contains an explicit port component of “80”, then the browser MUST convert the port component to be “443”

http://example.com:80 –> https://example.com:443

if the URI contains an explicit port component that is not equal to “80”, the port component value MUST be preserved

http://example.com:8080 –> https://example.com:8080

if the URI does not contain an explicit port component, the browser MUST NOT add one

http://example.com –> https://example.com


  • No Related Posts

HSTS problem on one computer, can it happen on other?

I need a solution

Hello, I have a problem maybe someone here can help me out with.

We host websites on dedicated Linux server and use Letsencrypt for SSL.

That works fune, but on bosses Chrome he is getting an SSL error and a warning that “the website uses HSTS” which prevents him from simply going Advanced->visit website. If he deletes a domain at chrome://net-internals/#hsts it works fine, but we have a file sharing system (Owncloud 9) at /files subfolder which still didn’t work until he deleted domain.com/files at same screen, and still he wasn’t able to log on, as after logging on he was shown same error screen.

The error shows only on his computer and it is Chrome related as everything works fine on Mozilla.

What we would like to know is this: is there a chance that someone else, like a random website visitor or a customer who may try to use shared link, may run into same problem, which would look bad (as it is a SSL error which prevents from viewing a website) and is there something I can look into to fix that server side? Thanks in advance.