HTTP Security Headers

                                       Crimson Security Group
                                                          We yearn security.....


HTTP security headers provide yet another layer of security by helping to mitigate attacks and security vulnerabilities.

A number of new HTTP headers have been introduced whose purpose is to help enhancing the security of a website. Some of these headers can be very useful protection against certain type of attacks, but their use is not widely spread in some cases.Latest attacks such as Click jacking, XSS Filter Bypassing..etc have dramatically affected the World Wide Web community.

The main idea is to specify security in an HTTP parameter that is set by the server and is sent along to the web browser as a part of the in-line response. A browser renders the content of that web page by scrutinizing(Examining) the HTTP headers and tries to invoke the specified security module in order to head off the attacks.

As the name implies, the protection parameters for a specific set of attack are declared by the developer as a part of the web server or application running on the server.

Most of these declarative security protection parameters are not the part of HTTP 1.1 specification, but are considered as vendor specific or customized security solutions related to a specific product. Usually, the declarative security in HTTP parameters is understood as the”X” factor protection. Most of the HTTP headers start with”X” in order to differentiate between standard HTTP 1.1 and normalized ones.Microsoft, Chrome and Mozilla have adopted this type of security.

Example : X-XSS-Protection, X-Content-Security-Policy,X-Frame-Options etc

Content-Security-Policy

It is a browser based mechanism that allows you to white list  locations from which your web application can load resources 

This policy helps prevent attacks such as Cross Site Scripting (XSS) and other code injection attacks by defining content sources which are approved and thus allowing the browser to load them.Involves deciding what policies you want to enforce, and then configuring them and using X-Content-Security-Policy to establish your policy.Allows the client to detect and block malicious scripts injected into the application by an attacker.

 

Example :

 Lets see the Directive keywords for Content Security Policy....

How it Helps ?

 

        

Reference Link:    

                       https://developer.mozilla.org/en-US/docs/Web/Security/CSP

                              http://www.slideshare.net/BinuRamakrishnan/content-security-policy-lessons-learned-at-yahoo-55438493

Strict-Transport-Security

HTTP Strict Transport Security (HSTS) is a security enhancement that restricts web browsers to access web servers solely over HTTPS. This ensures the connection cannot be establish through an insecure HTTP connection which could be susceptible to attacks. HSTS is defined in the response header as Strict-Transport-Security and once the supported browser receives that header it knows to deliver all information over HTTPS.

How it Works

In order to set up HTTP Strict Transport Security, it must first be enabled on your origin server. Once it is enabled on the server side, the web server will begin adding an additional response header to tell the browser to communicate solely over HTTPS

   Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

a)   max-age defines the time in seconds for which the web server should only    

      deliver through HTTPS 

b)   IncludeSubDomains is optimal. This will apply HSTS to all the site’s

      subdomains as well.

 c)  preload is also optional. The site owner can submit their website to the 

     preload list which is a list of sites hardcoded into Chrome as being HTTPS

     only. 

The following 3 points are common threats that HSTS is able to protect against. 

1) Attackers using an invalid certificate in the hopes the user will accept the

    bad cert

2) Old bookmarks that contain http:// or manually entered http:// urls that can be

    vulnerable to an attack 

3) Sites claiming to be fully HTTPS serving HTTP content

Due to HSTS’s strict rules, the above threats will no longer be relevant as it doesn’t allow the use of insecure HTTP.

 

Valid Settings :

The following values must exist over the secure connection (HTTPS) and are ineffective if accessed over HTTP.

* max-age=31536000 - Tells the user-agent to cache the domain in the STS list
   for one year.  

* max-age=31536000; includeSubDomains - Tells the user-agent to cache the
  domain in the STS list for one year and include any sub-domains. 

* max-age=0 - Tells the user-agent to remove, or not cache the host in the STS
   cache.
  
Invalid Settings :
 
 *  Setting the includeSubDomains directive on https://www.example.com where users can still  
     access the site at http://example.com. If example.com does not redirect to https://example.com
     and set the STS header, only direct requests to http://www.example.com will be automatically
     redirected to https://www.example.com by the user-agent. 

 *  max-age=60 - This only sets the domain in the STS cache for 60 seconds. This is not long
     enough to protect a user who accesses the site, goes to their local coffee shop and attempts to
     access the site over http first. 

 *  max-age=31536000 includeSubDomains - Directives must be separated by a ;. In this case
     Chrome will not add the site to the STS cache even though the max-age value is correct. 

 *  max-age=31536000, includeSubDomains - Same as above. 

 *  max-age=0 - While this is technically a valid configuration. Many sites may do this accidentally,
     thinking a value of 0 means forever.
 

 X-Frame-Options

Stop Clickjacking with one simple header

Where a website can be embedded in an IFRAME element, an attacker could socially engineer a situation where a victim is directed to a website under an attacker’s control that frames the target website. The attacker could then manipulate the victim into unknowingly performing actions on the target website. This attack is possible even with cross-site request forgery protection in place, and is known as "clickjacking", for more information please refer to https://www.owasp.org/index.php/Clickjacking. In order to avoid this, the "X-Frame-Options" header was created. This header lets the owner of the website decide which sites are allowed to frame their site.

The common recommendation is to set this header to either "SAMEORIGIN", which allows only resources which are part of the Same Origin Policy to frame the protected resource, or to "DENY", which denies any resource (local or remote) from attempting to frame the resource that also supplied the "X-Frame-Options" header. This is shown below:

 

                 X-Frame-Options: SAMEORIGIN

DENY - Denies any resource (local or remote) from attempting to frame the resource that also supplied the X-Frame-Options header 

SAMEORIGIN - Allows only resources which are apart of the same origin policy to frame the protected resource. 

ALLOW-FROM http://www.example.com - Allows a single serialized-origin (must have scheme) to frame the protected resource. This is only valid in Internet Explorer and Firefox. The default of other browsers is to allow any origin (as if X-Frame-Options was not set). 

X-XSS-Protection

This response header can be used to configure a user-agent's built in reflective XSS protection. Currently, only Microsoft's Internet Explorer, Google Chrome and Safari (WebKit) support this header.

The recommended configuration is to set this header to the following value, which will enable the XSS protection and instruct the browser to block the response in the event that a malicious script has been inserted from user input, instead of sanitizing:

                  X-XSS-Protection: 1; mode=block. 

Valid Settings :

 *  0 - Disables the XSS Protections offered by the user-agent. 

 *  1 - Enables the XSS Protections 

 * 1; mode=block - Enables XSS protections and instructs the user-agent to block

   the response in the event that script has been inserted from user input, instead

   of sanitizing. 

 * 1; report=http://site.com/report - A Chrome and WebKit only directive that 

   tells the user-agent to report potential XSS attacks to a single URL. Data will

   be POST'd to the report URL in JSON format

 Invalid Settings:

* 0; mode=block; - A common misconfiguration where the 0  value will disable

  protections even though the mode=block is defined. It should be noted that

  Chrome has been enhanced to fail closed and treat this as an invalid setting but

  still keep default XSS protections in place. 

* 1 mode=block; - All directives must be separated by a ;. Spaces and , are

   invalid separators. However, IE and Chrome will default to sanitizing the XSS 

  in this case but not enable blocking mode as everything after the 1 is 

  considered invalid.

X-Content-Type-Options

A nifty attack known as MIME type confusion was the reason this header was created. Most of the browsers employ a technique called MIME sniffing, that consists on taking an educate guess at what the content type of the server response is, instead of trusting what the header’s content type value says. Under certain circumstances, browsers can be tricked into making the incorrect decision, allowing attackers to execute malicious code on victim’s browsers. For more information please refer to https://en.wikipedia.org/wiki/Content_sniffing. 

"X-Content-Type-Options" can be used to prevent this "educated" guess from happening by setting the value of this header to "nosniff", as shown below:

                              X-Content-Type-Options: nosniff 

      nosniff - This is the only valid setting, it must match nosniff.

Please, note that Internet Explorer, Chrome and Safari have support for this header, but the Firefox team is still debating it:https://bugzilla.mozilla.org/show_bug.cgi?id=471020

CORS   ( cross-origin resource sharing )

Nowadays, websites are a rich and complex flow of information. It is common to find websites that interact with other websites, for example requesting resources such as JavaScript scripts and fonts. There is a mechanism known as cross-origin resource sharing (CORS) that makes this possible in a secure manner. As part of the CORS specification, a header known as "Access-Control-Allow-Origin" was defined. This header is used to determine which websites are allowed to access certain resources.  

As an example of this header, to permit https://www.example.com to request and integrate your site’s data and content would be the following:

       Access-Control-Allow-Origin: https://www.example.com

The use of a wildcard (*) is allowed, but not generally recommended. If a wildcard is used, anyone would be permitted to request and integrate your site’s data and content.

For a more detailed explanation of all the headers that are part of the CORS standard, and how they all work, please refer to the following resource: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS  

It is recommended that you do not set any CORS related headers unless you are sure you want to allow requests from other websites you do not control. A website that does not set any CORS headers, will not allow requests from any other sites.