Tightening the Security of HTTP Traffic Part 3

This is the third part of this article which provides guidelines for tightening the security of http traffic by leveraging the power of F5 Big-IP and  iRules to include the latest HTTP security headers to all HTTP responses. In this part, we will review additional steps that should be taken to make web applications even more secure.

You can access the first and second part of the article through following links.

Tightening the Security of HTTP Traffic Part 1

10. Headers to remove

10.1  The Server and  X-Powered-By headers

The Server and X-Powered-By headers are inserted by default in all HTTP responses. These headers are inserted by the web server (Apache, Nginx, Express...) and are not used by web clients for any purpose. 

The issue with these headers is that the detailed version of the web server software (Server) and the Application development environment (X-Powered-By) are published, and this could be useful information for a potential hacker. 

Since vulnerabilities are usually discovered for specific software versions, and exploits made available in some cases, publishing the version of the web server can weaken the security posture of the application, by making it possible, even for novices to attack the application. 

It is important to note that hiding the version of the software is not a very strong security mechanism, because it is always possible to discover application versions by using other finger printing techniques.

Good to remember: security by obscurity is not security.

10.2 Example: BAD

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

HTTP/1.1 200 OK

Server: Apache/2.2.15 (Oracle)

X-Powered-By: PHP/5.3.3

Set-Cookie: JSESSIONID=F5865E17B696B21FCBBF64808CA3A837; Path=/avs/; HttpOnly

Content-Type: text/html;charset=ISO-8859-1

Content-Language: en-US

Transfer-Encoding: chunked

[...]

10.3 Example: GOOD

 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

Content-Type: text/html; charset=utf-8

[...]

X-Frame-Options: SAMEORIGIN

Date: Thu, 13 Apr 2017 09:55:31 GMT

Connection: close

Content-Length: 111936

Strict-Transport-Security: max-age=16070400

Server: F5

[...]

 

11. Additional important security measures:

11.1 Cookie encryption

Cookies may contain sensitive information about the web application or the application hosting platform.

If supplied in clear text, this could cause significant security risk. Cookie encryption is recommended to improve the security of web applications.

Cookie encryption can easily be configured with BigIP via the http profile (Pre 11.6.0) or within the cookie persistence profile (post 11.6.0).

11.1.1 Example:

The following example was run in our internal lab with private IP addresses that are used here for illustration purposes only. You should change accordingly.

Steps to configure cookie encryption with Big-IP can be found here: K14784: Configuring cookie encryption within the HTTP profile (10.x - 13.x)

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

HTTP/1.1 302 Found

Server: Apache-Coyote/1.1

Set-Cookie: BIGipServerjt-pool=2181043210.20480.0000; path=/

[…]

The cookie value is in clear text and the pool member IP can be calculated. This is not desirable in most situations

K6917: Overview of BIG-IP persistence cookie encoding

After encryption

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

HTTP/1.1 302 Found

Server: Apache-Coyote/1.1

Set-Cookie: BIGipServerjt-pool=!EoKW9h6lBP6E7cWaJqgjmq49GcRmoK+IYTPiSvhvv+afQsG5MpjN4cuDy9PLtYMGNmtumzSAZ/KYwXc=; path=/

 

11.2 Https (SSL/TLS)

• Protection of bulk http content happens over https. Most previously discussed headers will be meaningless if the traffic is transferred in plaintext over HTTP. HTTPS is the de-facto mechanism to secure HTTP traffic.

• Transport Layer Security (TLS), and its predecessor, Secure Sockets Layer (SSL) are communication protocols designed to provide secure data transfer over insecure networks.
• SSL/TLS protocol goal is achieved by combining several cryptographic mechanism and primitives, with careful implementation constraints.

Security services provided by SSL/TLS include:

• Confidentiality: This is the assurance that private information can only be viewed by the authorized recipients.
• Data integrity: This is the assurance that data exchanged between parties is not modified in transit, whether accidentally or intentionally by an attacker
• Data Origin Authentication: This service provides the assurance that an entity claiming to be the source of some data is indeed the source of the data.
• Entity authentication: This is the active (live) authentication of communicating parties.

Https (SSL/TLS) communication setup

• When a client requests to communicate to a server via HTTPS, a SSL/TLS session is setup.
• The session starts with a handshake during which security parameters are exchanged.
• The server sends its certificate to the client to prove its identity
• The client verifies the signature on the certificate using the verification key of the certificate authority (CA).
• The client then generates a session key which will be used to encrypt the traffic during the session.
• Both clients and server may generate the session key (depending on the key exchange algorithm).

11.2.1 iRule to redirect all HTTP request to HTTPS

when HTTP_REQUEST {
   HTTP::redirect https://[getfield [HTTP::host] ":" 1][HTTP::uri]
}