Something that frequently comes up on those security penetration tests we all have to endure (unfortunately for good reason) is the lack of or inconsistency in providing the X-Content-Type-Options HTTP header in web server responses. This might be an irritant but the safer our site and it’s visitors the better.
What good is this header anyway? It’s simple; Chrome and Internet Explorer have a so-called ‘MIME-Sniffing’ feature which is enabled by default and detects the type of content found in a web server response. This is used to better display a web page, even if the web server gets something wrong, or a page is poorly written and has specified an incorrect content type.
For instance, a site may send a response stating the included content is text, via the Content-Type header and a value of text/plain. The browser will detect it’s actually a PDF and display that PDF correctly. Otherwise it might attempt to render it as text, resulting in a mangled or unreadable page. For some browser developers, that pretty page is better than complying with standards.
Doesn’t sound too bad? Well, any software you might employ in your browser to prevent the download, display or execution of certain types of content can potentially be bypassed through this feature. There’s plenty of reasons we may want to block executables, zip files, Word files and the like. On Windows it is still possible to ‘own’ a PC with just a GIF image.
Any software we use to protect against such threats by blocking this content can only inspect the value of the Content-Type header and act appropriately based on it’s value. The browser doing something completely different to what might be expected isn’t helpful and presents a risk.
The beauty of using a load balancer is that we only have to do this in a single place in order to deploy this to all our servers. We don’t need to rely on developers or Apache reconfigurations. On the edgeNEXUS load balancer we just import a jetPACK configuration template and assign a flightPATH traffic rule to whichever Virtual Service(s) we wish to protect.
The rule only adds the header if it doesn’t exist so it’ll work even where our web servers already insert it or only insert it for specific pages. This rule should be part of your standard Virtual Service configuration – you’ve nothing to lose whatever the site although of course, testing is always recommended. You can download the jetPACK on the edgeNEXUS Github site here.
This is one of many flightPATH rules we’ve developed, which you can deploy to improve the security of your site and it’s users. For more around security related HTTP Headers, check out these articles:
- A HTTP Security Header to Combat ‘Clickjacking’ – How to Improve your Site’s Security with the X-Frame Options Header
- How to Secure HTTP Traffic and Protect Users with the HTTP Strict Transport Security Header
The beauty of using a load balancer is that we only have to do this in a single place in order to deploy this to all our servers. We don’t need to rely on developers or Apache reconfigurations.
