Tightening the Security of HTTP Traffic part 1

Summary

HTTP is the de facto protocol used to communicate over the internet. The security challenges that exists today was not considered when designing the HTTP protocol. Web browsers are generally used to interact with web applications. However, this interaction is not secured in most deployments, despite the existence of a number of http headers that can be leveraged by application developers to tighten the security of their applications.

In this article, I will give an overview of some important headers that can be added to HTTP responses in order to improve the security web applications. I will also provide sample iRules that can be implemented on F5 BigIP to insert those headers in HTTP responses.

Content

This article has been made in a series of 3 parts to make it easier to read and digest. The following headers will be reviewed in different parts of this article:

Part 1:

• A brief overview of Cross-Site Scripting (XSS) vulnerability
• X-XSS-Protection
• HttpOnly flag for cookies
• Secure flag for cookies

Part 2:

• The X-Frame Options Header
• HTTP Strict Transport Security
• X-Content-Type-Options
• Content-Security-Policy
• Public Key Pinning Extension for HTTP (HPKP)

Part 3:

• Server and X-Powered-By
• Cookie encryption
• Https (SSL/TLS)

A brief overview of XSS Attacks

Before going further into the details of the headers we need to implement to improve the security of http traffic, it is important to make a quick review of  the Cross-Site Scripting (XSS) attack, which is the most prevalent web application security flaw . This is important because any of the security measure we will review may be completely useless if an XSS flaw exist on the application. The security measures proposed in this article rely on the browser not infected by any kind of malware (including XSS) and working properly.

A Cross-Site Scripting (XSS) attack is a type of injection attack where a malicious script is injected into a trusted but vulnerable web applications. The malicious script is send to victim browser as client side script when the user uses a vulnerable web app. XSS are generally caused by poor input validation or encoding by web application developers.

An XSS attack can load a malware (JavaScript) into to browser and make it behave in a completely unpredictable manner, thus making all other protection mechanism useless. 

Cross-Site scripting was ranked third in the last OWASP 2013 top 10 security vulnerabilities. Detailed information on XSS can be found on OWASP website.

1. The X-XSS-Protection header

The X-XSS-Protection header enables the Cross-Site Scripting filter on the browser. When enabled, the XSS Filter operates as a browser component with visibility into all requests / responses flowing through the browser. When the filter detects a likely XSS in a request or response, it prevents the malicious script from executing.

The X-XSS-Protection header is supported by most major browsers.

Usage: 

1. X-XSS-Protection: 0
   • XSS protection filter is disabled (facebook)
2. X-XSS-Protection: 1
   • XSS protection filter is enable. Upon XSS attack detection, the browser will sanitize the page.
3. X-XSS-Protection: 1; mode=block
   • If XSS attack is detected, The browser blocks the page in order to stop the attack. (Google, Twitter)

Note:

If third party scripts are allowed to run on your web application, enabling XSS-Protection might prevents some scripts from working properly. As such, proper considerations should be made before enabling the header.

1.1 Example of how this header is used:

the following command can be used to see which  http headers are enabled on a web application.

This command sends a single http request to the destination application and follows redirection. Therefore it is completely harmless and is only used for educational purposes in this article.

I will use the same command throughout the article against somes well known sites, that are build with high security standards, in order to demonstrate how the discussed headers are used in real life.

curl -L -A "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0" -sD - https://www.google.com -o /dev/null

HTTP/1.1 200 OK
Date: Mon, 07 Aug 2017 11:24:08 GMT
Expires: -1
Cache-Control: private, max-age=0
Server: gws
X-XSS-Protection: 1; mode=block

[...]

1.2 iRule to enable XSS-Protection

The following iRule can be used to insert XSS-Protection header to all http responses:

 
when HTTP_RESPONSE {
 if {  !([ HTTP::header exists "X-XSS-Protection“ ])} {

   HTTP::header insert "X-XSS-Protection" "1; mode=block"  
}
 }

2.  HttpOnly flag for cookies

When added to cookies in HTTP responses, the HttpOnly flag prevents client side scripts from accessing cookies. Existing cross-site scripting flaws on the web application will not be exploited by using this cookie. The HttpOnly flag relies on the browser to prevent XSS attacks, when set by the server.This flag is supported by all major browsers  in their latest versions. It was Introduced in 2002 by Microsoft in IE6 SP1.

Note: Using older browser exposes you to higher security risk as older browsers may not support some of the security headers discussed in this article.

2.1 Example:

curl -L -A "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0" -sD - https://www.google.com -o /dev/null

HTTP/1.1 200 OK
Date: Wed, 16 Aug 2017 19:34:36 GMT
Expires: -1
[..]
Server: gws
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Set-Cookie: NID=110=rKlFElgqL3YuhyKtxcIr0PiSE; expires=Thu, 15-Feb-2018 19:34:36 GMT; path=/; domain=.google.com; HttpOnly
Alt-Svc: quic=":443"; ma=2592000; v="39,38,37,35"
[...]

2.2 iRule to add HttpOnly flag  to all cookies for http responses:

If added to Big-IP LTM virtual server, the following iRule will add the HttpOnly flag to all cookies in http responses.

 
when HTTP_RESPONSE {
  foreach mycookie [HTTP::cookie names] {
   HTTP::cookie httponly $mycookie enable
  }
}

3. Secure flag for cookies

The purpose of the secure flag is to prevent cookies from being observed by unauthorized parties due to the transmission of a the cookie in clear text. When a cookie has the secure flag attribute, Browsers that support the secure flag will only send this cookie within a secure session(HTTPS). This means that, if the web application accidentally points to a hard coded http link, the cookie will not be send.

• Enabling secure flag for cookies is common and recommended

3.1 Example

curl -L -A "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0" -s -D - https://www.f5.com -o /dev/null

HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=utf-8
[…]
Set-Cookie: BIGipServer=!M+eTuU0mHEu4R8mBiet1HZsOy/41nDC5VnWBAlE5bvU0446qCYN4w/jKbf2+U8d8EVe+BxHFZ5+UJYg=; path=/; Httponly; Secure
Strict-Transport-Security: max-age=16070400
[…]

3.2 Setting the secure flag with iRule

If added to Big-IP LTM virtual server, the following iRule will add the secure flag to all http responses.

 
when HTTP_RESPONSE {
  foreach mycookie [HTTP::cookie names] {
   HTTP::cookie secure $mycookie enable
  }
}