Enterprises are rapidly adopting cloud applications across various functions. It is important to consider the enterprise readiness of these applications as they are being used to store sensitive data. An important aspect of this is the susceptibility of these applications to attacks that could compromise the data. In this blog post we will look at the advances being made in the realm of http protocol that would address these threats and the adoption of these techniques across the universe of cloud applications.
In the past decade, myriad techniques have been developed to compromise web applications, ranging from cross site scripting (XSS) and SQL injection to phishing and clickjacking. As web applications have become more sophisticated, so have modern web browsers which in turn has spurned newer attacks and, consequently, their defenses. HTTP security headers are a set of new HTTP response headers proposed to help enhance a website’s security. These headers turn on the inbuilt defense mechanisms in a compatible browser and protect from XSS, clickjacking, MIME sniffing vulnerabilities and Man-In-The-Middle attacks etc.
What are HTTP Security Headers?
The following are 5 security headers and a brief introduction to each of them.
- HTTP Strict-Transport-Security (HSTS):
HSTS headers protect against Man-In-The-Middle attacks. If a website uses an HSTS header, the header enforces that all content from the domain is downloaded over HTTPS and also refuses to connect in case of certificate errors and warnings. A typical HSTS response header looks like:
Strict-Transport-Security: max-age=31536000; includeSubDomains
For example: If the website http://foobar.com includes an HSTS header in the response, then next time on connecting to foobar.com, the browser will force a connection to https://foobar.com.
- Content-Security-Policy (CSP):
The Web’s security model is strongly dependent on the same origin policy. Basically, the content from https://foobar.com should only have access to data from https://foobar.com and should not have access to https://evil.com.
In a cross-site scripting (XSS) attack, the browser is tricked into delivering malicious content by bypassing the same origin policy. The root cause in case of XSS is the browser’s inability to distinguish between the scripts that are part of the application and scripts which have been injected by a third party.
CSP provides a mechanism to instruct browsers on what to trust. By using CSP, a allow list policy is enforced on the content being delivered, i.e, content can only be delivered by certain specified domains.
For example: by specifying following in the HTTP response header:
Content-Security-Policy: script-src ‘self’ https://apis.google.com
the browser is instructed to load scripts only from the current domain and apis.google.com.
Content delivery for the following types can be allow listed using CSP: javascripts, css, html frames, fonts, images, embeddable objects – java applet, activex ,audio, video files.
CSP also provides the ability to automatically turn on sandbox mode for all iframes on a website. CSP protects against XSS, data injection attacks, protection against data theft, distribution of malware etc.
- X-Frame-Options:
X-Frame-Options is a simple solution for preventing Clickjacking attacks. Inclusion of this header in an HTTP response enforces the browser to evaluate a request of framing a page. ‘SAMEORIGIN‘ value will allow the page to be displayed in a frame on the same origin as the page, while ‘ALLOW FROM https://foobar.com‘ allows framing of the page only on https://foobar.com.
For example: Specifying the following:
X-Frame-Options:Deny
prevents the page to be displayed in a frame.
- X-Content-Type-Options:
Most browsers employ a technique called MIME sniffing which consists of guessing the content type returned by a server. Instead of trusting the HTTP response header called content-type value, under certain circumstances browsers can be tricked into making an incorrect guess about the content type, allowing attackers to execute malicious code on a victim’s browser.
For example: Specifying the following:
X-Content-Type-Options: nosniff
prevents the browser from guessing about the MIME type and hence prevents the browser from protecting against MIME content-sniffing attacks.
- XSS-Protection:
This header provides the ability to turn on the browser’s inbuilt XSS protection.
A typical response header will look like:
X-XSS-Protection: 1; mode=block
This will enable XSS protections and instructs the browser to block the response in the event a XSS reflection attack is detected.
Usage of Security Headers by SaaS Apps
At Netskope we are continuously monitoring SaaS applications and in our research we have identified around 941 SaaS apps using at least one of the security headers. Here are a few other statistics on the usage of security headers:
| Apps with 5 security headers | 7 (<1% of apps) |
| Apps with 4 security headers | 73 (<1% of apps) |
| Apps with 3 security headers | 170 (1.7% of apps) |
| Apps with 2 security headers | 159 (1.6% of apps) |
| Apps with 1 security headers | 532 (5.3% of apps) |
Table 1. Distribution of Apps using unique number of Security Headers
| HTTP Strict Transport Security | 332 (3.3% of apps) |
| Content Security Policy (CSP) | 18 (<1% of apps) |
| X-Frame-Options | 715 (7.1% of apps) |
| X-Content-Type-Options | 341 (3.4% of apps) |
| XSS-Protection | 281 (2.8% of apps) |
Table 2. Distribution of Apps using each of the Security Headers
Image 1. Apps which implemented all the 5 Security Headers
We can observe from Table 1. that only 7 SaaS apps (as shown in Image 1) use all 5 security headers. The distributions also show the low rate of adoption of security headers. The X-Frame-Option is considered to be the most easy to implement header as it does not involve changing websites behavior, and thus X-Frame-Options find the highest adoption rate. CSP is the most comprehensive of all the security headers and considered the hardest to implement, and thus lies at the bottom of the list in terms of usage among the 5 headers.
Apart from the above discussed HTTP security headers, there are a few more security headers under various stages of implementation, HTTP public key pinning (HPKP) being one of them. Since these headers are fairly new, their adoption rate is negligent and thus not covered in this post.
The HTTP security headers use the inherent power of the latest browsers and protect against significant threats which are observed over the Internet today. We urge SaaS app vendors to adopt them into their app implementations.
