By Manish Tanwar
World Informatix Cyber Security
Cyber security is a hot topic for all the users who use internet on daily basis. It becomes a matter of great importance if the user is not aware of basic security practices. Individuals may or may not have knowledge of basic security practices during internet surfing which may lead to some serious issues and result in losing sensitive data.
Attackers are exploiting vulnerabilities in popular websites and targeting users of the victim website. Website security engineers may not be aware of the newly discovered flaw and attackers keep tricking visitors of the website till the path of the vulnerability. Its important to protect users from such hidden vulnerabilities.
There are few vulnerabilities which are common in web applications and attacker looks for most of time client tricking vulnerabilities like Cross Site Scripting, Click Jacking, Cross Origin resource sharing, absence of content security policies etc. These vulnerabilities can be mitigated up to an extent using HTTP security header on modern web browsers. This security measure doesn’t mitigate risk of attacks completely but attacker need to try hard for exploitation of client-side vulnerabilities. Implementation of HTTP security headers reduce the efforts of security engineers team as well as website users (just reduce the impact of attack). Lets have a look and discuss common security headers.
X-Frame-Options
This HTTP security header mitigates clickjacking attack issue on implemented web page.
X-Frame-Options is used to indicate whether the browser can render a page in an iframe, frame or object. The three possible values are:
DENY: The page cannot be rendered in a frame under any circumstance.
SAMEORIGIN: The page can only be displayed in a frame if the “framing” site is on the same origin.
ALLOW-FROM : The page can only be framed from a specific origin.
Clickjacking is having a target site rendered in a frame by an attacking site, by setting this header such attacks can be mitagate. It is highly recommended to use X-Frame-Options instead of other protections against clickjacking. For example, in the past framebusting scripts were found to be insufficient in protecting against clickjacking.
X-Content-Type-Options
MIME content sniffing is a security issue that arises when browsers try to guess the content of the files it renders. For instance, if an image file contains HTML tags in its comments and it was served with a content type not used for serving images, the browser will attempt to guess how to render the content. As soon as it sees the HTML elements it will be rendered as HTML, which can contain active content such as scripts, Flash, etc., turning an innocent image file into a potential threat. This header makes the browser load the content and display it if the content-type is the one expected.
X-Content-Type-Options has only one possible value: nosniff. This HTTP security header is supported by Internet Explorer and Chrome.
Access-Control-Allow-Origin
Cross-Origin Resource Sharing (CORS) allows websites to share content between themselves. It is common for modern websites to fetch content, such as scripts, style sheets and fonts, from third party sites.
This header allows the definition of third party websites that are permitted to access a given resource. It can be used as a mechanism to relax the restrictions imposed by Same Origin Policy, enabling sites to choose which origins are allowed to fetch its resources. When sending “non-trivial” requests with XmlHttpRequest using verbs like PUT or DELETE, as well as containing Content-Type values other than application/x-www-form-urlencoded, multipart/form-data or text/plain, CORS plays an important role by checking whether or not the origin is authorised to perform such request.
X-XSS-Protection
Modern browsers have built-in filters to protect against reflected cross-site scripting. The purpose of this header is to enable or disable the protection offered by the browser.
XSS-Protection can have the values of 0 and 1, to disable or enable the protection, respectively, as well as 1;mode=block and 1;report=uri. The former enables the protection and blocks the response instead of attempting to sanitize it. The latter also enables the filter and reports the incident to a URL via a POST request.
HTTP Strict Transport Security (HSTS)
With the increasing popularity of attacks such as sslstrip, FireSheep and other more sophisticated man-in-the-middle techniques, HSTS forms a strong countermeasure against MITM.
A server implements HSTS by setting the header Strict-Transport-Security with the appropriate expiration value and delivers the message over a HTTPS connection (for obvious reasons the header is ignored if delivered via clear text channel). Values for Strict-Transport-Security are max-age, used to set the number of seconds in which the HSTS set up will be valid for that domain in the browser, and includeSubDomains, used to indicate that subdomains should also be covered.
The final result is that the browser turns any insecure (non-HTTPS) links in the application into secure ones. Moreover, in case the server certificate is invalid, the connection will not proceed. This HTTP security header dramatically reduces the risk of man-in-the-middle attacks in the web.
Content Security Policy
Content Security Policy (CSP) is a security mechanism invented by Mozilla that gained significant popularity in the past year. This mechanism works as a whitelist and its purpose is to tighten how the browser loads resources such as scripts, fonts, images, CSS, media, applets, etc.
CSP is currently being touted as a very strong protection against cross-site scripting attacks. When correctly implemented, content security policy restricts the usage of inline Java Script, DOM event attributes such as onload, onclick, anchor tags that start with the “javascript://” URL scheme. Also, the usage of eval() is restricted. It mandates that scripts can only be loaded from a pre-defined URL.
In this manner, a XSS payloads such as <img src=x onerror=alert(1)> or <script src=https://attacker.com/malicious.js> will not have any effect even if the application is vulnerable to cross-site scripting.
Currently there is no consensus as to how browsers need to be informed about CSP, but the Content-Security-Policy header is the most supported method.
The standard way the policy is sent from the application to the browser is by setting the header in the following manner:
Content-Security-Policy: policy
Writing CSP policies can be a complex task depending on the application. The following example from Mozilla illustrates the policy well:
Content-Security-Policy: default-src ‘self’; img-src *; media-src media1.com media2.com; script-src userscripts.example.com
The above policy says:
Images can be loaded from anywhere in the web
Media can only be loaded from media1.com and media2.com domains
Scripts can only be loaded from userscripts.example.com
default-src ‘self’ sets the value to other policies to the same domain as the application (hence, “self”). This directive establishes the default fallback to the other policies when they are not explicitly defined.
Just like with other HTTP security header, violations of the policy can be reported with the use of the optional report-uri field.
Above mentioned are some HTTP security header which enhance the web application user security on client side. These header values reduce the attack but doesn’t mitigate them so its always recommended to patch the vulnerabilities on application code level.