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.
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
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.
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]
}
