Introduction
HTTP security headers are a subset of HTTP headers that communicate the security features of HTTP communication between a web client (typically a browser) and a server. Some HTTP headers that are indirectly related to privacy and security may also be referred to as HTTP security headers. By enabling appropriate headers in web apps and web server settings, you can strengthen your online application's resistance to several common threats, such as cross-site scripting (XSS) and click jacking.
HTTP security Header Types
1. X-Frame-Options
2. Cross-Site Scripting Protection (X-XSS)
3. X-Content-Type-Options
4. Strict Transport Security
HTTP security Header Types
X-Frame-Options
The X-Frame Alternatives The HTTP response header can be used to specify whether a browser should be permitted to render a page in a frame>, iframe>, embed>, or object>.Sites can use this to avoid click-jacking attacks by ensuring that their content is not embedded in the content of other sites. Other supported values include same-origin, which allow loading into iframes with the same origin, and allow –from, which allows loading from specific URLS. This header is typically replaced by appropriate CSP directives.
XFO is a header that helps to protect your visitors against clickjacking attacks. It is recommended that you use the X-Frame-Options header on pages which should not be allowed to render a page in a frame.
How It Works...
- To enable the SAMEORIGIN option across a website, the X-Frame-Options header must be returned as part of the HTTP response for each individual page (cannot be applied cross-site).
- X-Frame-Options is incompatible with multi-domain sites that require framed content to be displayed between them because it does not support a whitelist of acceptable domains.
- Because only one option can be used on a single page, the same page cannot be displayed as a frame on both the current and external websites.
- The ALLOW-FROM setting is not supported by all browsers.
- X-Frame-Options is a defunct option in most browsers.
Cross-Site Scripting Protection (X-XSS)
- The Cross-Site Scripting Protection (X-XSS-Protection) header was introduced to protect against JavaScript injection attacks via cross-site scripting, as the name implies. This non-standard header was designed for browsers with XSS filters and provided control over the filtering capabilities. In practice, it was very easy to get around or abuse, and because modern browsers do not perform XSS screening, the header is now obsolete.
- If a cross-site scripting attack is detected, the browser will remove the unsafe parts and enables XSS filtering.
How it works...
- Stored (persistent XSS) - These vulnerabilities happen when unsanitized user input (and therefore the XSS payload) is saved on the server side, typically in a database...
- Reflected (non-persistent XSS)- A reflected XSS vulnerability happens when unsanitized user input from a URL or web form is directly used (reflected) on the page. As a non-persistent vulnerability, it allows the attacker to inject malicious content into one specific request
- DOM-based XSS- DOM-based XSS vulnerabilities are different in that the attack happens entirely inside the browser, specifically in the DOM (Document Object Model) of the current web page.
How to Prevent Vulnerabilities
- As with all injection attacks, the root cause of cross-site scripting vulnerabilities is insufficient validation and sanitization of user inputs.
- To prevent XSS security vulnerabilities, you need to apply context-dependent output encoding.
- In some cases, it may be enough to encode HTML special characters (such as opening and closing tags), but in general, correctly applied URL encoding will be more secure.
- You should only accept links with whitelisted protocols to prevent the abuse of URI schemes such as JavaScript: //.
- For DOM-based XSS, you also need to be careful where you write user-controllable values.
X-Content-Type-Options
- The HTTP headers X-Content-Type-Options acts as a markerthat indicates the MIME-types headers in the content type’sheaders should not be changed to the server. This header was introduced in the Internet Explorer 8 of Microsoft. This header block the content sniffing (non-executable MIME type into executable MIME type). After that, all the other browsers also introduce the X-Content-Type-Options, and their MIME sniffing algorithms were less aggressive.
- Syntax:
x-content-type-options: nosniff
How it works
- The X-Content-Type-Options header only has one possible value “X-Content-Type-Options: nosniff”. Enabling it informs the user’s browser that it must not perform MIME type sniffing and instead rely on the explicitly declared value. Without this setting, if a malicious JavaScript file was disguised as an image such as a PNG, then the JavaScript file would be executed. With X-Content-Type-Options enabled the file will be treated as an image that fails to load as the file isn’t a valid image format.
- X-Content-Type-Options isn’t particularly necessary on a website that uses entirely first-party resources, as there’s no chance of a malicious file being accidentally served. If a website uses third-party content such as external, or user-submitted resources, then X-Content-Type-Options provides protection against this type of attack.
Strict Transport Security
- HTTP Strict Transport Security (HSTS) is a policy mechanism that helps to protect websites against man-in-the-middle attacks such as protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should automatically interact with it using only HTTPS connections, which provide Transport Layer Security (TLS/SSL), unlike the insecure HTTP used alone. HSTS is an IETF standards track protocol and is specified in RFC 6797
- The HSTS Policy is communicated by the server to the user agent via an HTTP response header field named “Strict-Transport-Security ". HSTS Policy specifies a period of time during which the user agent should only access the server in a secure fashion. Websites using HSTS often do not accept clear text HTTP, either by rejecting connections over HTTP or systematically redirecting users to HTTPS (though this is not required by the specification). The consequence of this is that a user-agent not capable of doing TLS will not be able to connect to the site.
How it works
- A server implements an HSTS policy by supplying a header over an HTTPS connection (HSTS headers over HTTP are ignored).
- For example, a server could send a header such that future requests to the domain for the next year (max-age Specification history HSTS mechanism overview is specified in seconds; 31,536,000 is equal to one non-leap year) use only HTTPS:
Strict-Transport-Security: max-age=31536000
- When a web application issues HSTS Policy to user agents, conformant user agents behave as follows (RFC 6797):
- Automatically turn any insecure links referencing the web application into secure links (e.g. http://example.com/some/page/ will be modified to https: //example.com/some page/ before accessing the server).
- If the security of the connection cannot be ensured (e.g. the server's TLS certificate is not trusted), the user agent must terminate the connection (RFC 6797 section 8.4, Errors in Secure Transport Establishment) and should not allow the user to access the web application.
Why is it important
- The HSTS Policy helps protect web application users against some passive (eavesdropping) and active network attacks.
- A man-in-the-middle attacker has a greatly reduced ability to intercept requests and responses between a user and a web application server while the user's browser has HSTS Policy in effect for that web application.
Which Vulnerabilities can it Prevent?
- The most important security vulnerability that HSTS can fix is SSL-stripping man in-the-middle attacks, first publicly introduced by Moxie Marlinspike in his 2009 BlackHat Federal talk "New Tricks For Defeating SSL In Practice ". The SSL (and TLS) stripping attack works by transparently converting a secure HTTPS connection into a plain HTTP connection. The user can see that the connection is insecure, but crucially there is no way of knowing whether the connection should be secure. At the time of Marlinspike's talk, many websites did not use TLS/SSL, therefore there was no way of knowing (without prior knowledge) whether the use of plain HTTP was due to an attack, or simply because the website hadn't implemented TLS/SSL. Additionally, no warnings are presented to the user during the downgrade process, making the attack fairly subtle to all but the most vigilant. Marlinspike's sslstrip tool fully automates the attack.
- HSTS addresses this problem by informing the browser that connections to the site should always use TLS/SSL. The HSTS header can be stripped by the attacker Applicability if this is the user's first visit. Google Chrome, Mozilla Firefox, Internet Explorer and Microsoft Edge attempt to limit this problem by including a "pre-loaded" list of HSTS sites.
- HSTS can also help to prevent having one's cookie-based website login credentials stolen by widely available tools such as Firesheep. Because HSTS is time limited, it is sensitive to attacks involving shifting the victim's computer time e.g. using false NTP packets
Disadvantages
- HSTS can be used to near-indelibly tag visiting browsers with recoverable identifying data (supercookies) which can persist in and out of browser "incognito" privacy modes. By creating a web page that makes multiple HTTP requests to selected domains, for example, if twenty browser requests to twenty different domains are used, theoretically over one million visitors can be distinguished (2^20) due to the resulting requests arriving via HTTP vs. HTTPS; the latter being the previously recorded binary "bits" established earlier via HSTS headers.
- The initial request remains unprotected from active attacks if it uses an insecure protocol such as plain HTTP or if the URI for the initial request was obtained over an insecure channel. The same applies to the first request after the activity period specified in the advertised HSTS Policy.
Even with an "HSTS preloaded
list", HSTS can't prevent advanced attacks against
TLS itself, such as the BEAST or CRIME attacks introduced by Juliano Rizzo and
Thai Duong.
How HTTP Security Headers can Improve Web Application Security...
- Enabling XSS Filtering
- Controlling Framing
- Disabling Caching Of Confidential Resources
- Enforcing HTTPS
- Explicitly Whitelisting Sources
- Preventing Content-Type Sniffing
