Hello HUE admin,
Recently we have added many security options in HUE. These are turned on by default when possible.
This document describes some of the fixes and enables Hue administrators to enforce and manage secure HUE installation. Whenever a browser requests a page from a HUE web server, HUE responds with the content along with HTTP Response Headers. Some of these headers contain content meta data such as the content-encoding, cache-control, status error codes, etc. Along with these are also HTTP security headers that tell your browser how to behave when handling HUE’s content. For example, by using the strict-transport-security you can force the browser to communicate solely over HTTPS.
The new Content-Security-Policy HTTP response header helps you reduce XSS risks on modern browsers by declaring what dynamic resources are allowed to load via a HTTP Header. (Read more here: https://content-security-policy.com/)
If you want to turn off content-security-policy header then use following value. (Beware use it on your own risk)
If you want to disable declaring what dynamic resources are allowed to load via a HTTP Header then you can use following value. (Use it on your own risk)
Example of image content blocked
HUE now minimizes disclosure of web server information to minimize insight about web server it’s version or other details. No change is needed from end user. Produces following HTTP response header :
Some browsers will try to guess the content types of the assets that they fetch, overriding the Content-Type header. To prevent the browser from guessing the content type, and force it to always use the type provided in the Content-Type header, you can pass the X-Content-Type-Options: nosniff header.
Some browsers have ability to block content that appears to be an XSS attack. They work by looking for Javascript content in the GET or POST parameters of a page. To enable the XSS filter in the browser, and force it to always block suspected XSS attacks, you can pass the X-XSS-Protection: 1; mode=block header.
Example of the new headers received with above options
If your HUE site offers both HTTP and HTTPS connections, most users will end up with an unsecured connection by default. For best security, you should redirect all HTTP connections to HTTPS. For sites that should only be accessed over HTTPS, you can instruct newer browsers to refuse to connect to your domain name via an insecure connection (for a given period of time) by setting the “Strict-Transport-Security” header. This reduces your exposure to some SSL-stripping man-in-the-middle (MITM) attacks. In HUE it is now enabled by default to switch to https if https is enabled.
HUE now delivers csrftoken and session cookies with secure bit set if possible. When a secure flag is used the cookie will only be sent over HTTPS.
Session cookie with secure bit while csrftoken is not
Hue now supports Wildcard certificates. It adds the missing functionality of validating wildcard certificates and certificates with SANs (subjectAlternativeName).
A single wildcard certificate for *.example.com, will secure all these domains:
Instead of getting separate certificates for sub domains, you can use a single certificate for all main domains and sub domains and save your money.
Because the wildcard only covers one level of subdomains (the asterisk doesn’t match full stops), these domains would not be valid for the certificate:
Fixed Arbitrary host header acceptance in Hue. Now one can set host/domain names that the Hue server can serve.
allowed_hosts=”host.domain,host2.domain,host3.domain”
Django CVE-2015-5143 http://www.cvedetails.com/cve/CVE-2015-5143/
Django CVE-2015-2316 http://www.cvedetails.com/cve/CVE-2015-2316/
Hue Team