This is the second 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.
You can access the first and last part of the article through following links.
The X-Frame-Options header protects web applications against Clickjacking. It Instructs browsers on how to display frame or iFrame (an HTML document within another HTML document).
Possible X-Frame-Option values are:
DENY: Do not render data within iframes (Facebook)
SAMEORIGIN: Only render data in iframes from same origin (Google)
ALLOW-FROM: <DOMAIN>: Only render data in iframes from the specified domain
4.1 - About ClickJacking:
Attacker tricks a non suspecting user to click a button, a link or an area of the document that they did not intent to click.
Generally achieved with combination of transparent or opaque iframes, CSS and text boxes.
Relatively common attack
4.2 iRule to add The X-Frame-Options Header
when HTTP_RESPONSE {
if { !([ HTTP::header exists "X-Frame-Options“ ])} { HTTP::header insert "X-Frame-Options" "SAMEORIGIN" }
}
This iRule adds the X-Frame-Options : SAMEORIGIN to the header of all http response
The browser will only display iframes from the same origin on a given web page.
4.3 Example outcome:
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
The HSTS header Instructs web browsers to only use HTTPS protocol when communicating with the application. This Protects web applications against protocol downgrade and cookie hijacking attacks. A common example of the benefit of HSTS is when legacy and sometime recent applications contain hard codded http links, and those links transmits cookies or other sensitive information within http connections while the application is intended to use https. With HSTS enable, those links will be broken and the application protected (The application will fail securely).
Using HSTS in conjunction with the secure flag for cookies will provide stronger security and avoid broken links that may result in following an http link without supplying cookies.
HSTS is communicated to clients using "Strict-Transport-Security“ header. It is defined by IETF in RFC 6797.
5.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 Set-Cookie: dnn_IsMobile=False; path=/; HttpOnly Connection: close Content-Length: 83328 Set-Cookie: BIGipServer=!M+eTuU0mHEu4R8mBiet1HZsOy/41nDC5VnWBAlE5bvU0446qCYN4w/jKbf2+U8d8EVe+BxHFZ5+UJYg=; path=/; Httponly; Secure Strict-Transport-Security: max-age=16070400 [..]
5.2 iRule to enable HSTS for all HTTP responses
when HTTP_RESPONSE {
if { !([ HTTP::header exists "Strict-Transport-Security“ ])} { HTTP::header insert "Strict-Transport-Security" "max-age=16070400" }
}
The above iRule adds HSTS to all HTTP responses with a timeout of 16070400 seconds, which instructs browsers to only use HTTPS when accessing this site for the next 6 month (16070400 seconds)
6. X-Content-Type-Options
The X-Content-Type-Options is a security header that helps reduce risks to MIME type attacks. It Instructs the browser to only load content when the type matches the type specified in the Content-Type header. For instance, if "X-Content-Type-Options: nosniff“ header is send by the web application, compatible browsers, will not load a CSS file, unless the Content-Type matches “text/css”. this header has Only one valid value: nosniff
Equally browsers will not load scripts unless the MIME type matches “text/javascript”, “application/javascript”, “text/vbscript”…etc.
6.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.facebook.com -o /dev/null
HPKP is a security mechanism that helps prevent web origin impersonation where attackers could forge CA certificates. It Provides a list of public key hashes for the site certificates. Browser that support HPKP will cache the hashes when the user first visits the site, and verify the match on subsequent visits of the site by the same browser. HPKP uses the Trust On first Use (TOFU) Mechanism. The HTTP header for HPKP is “Public-Key-Pins” or “Public-Key-Pins-Report-Only”.
Public-Key-Pins-Report-Only:
Used to test HPKP
Errors are reported, the site is not blocked
A report URI must also be provided.
Public-Key-Pins:
This indicates full HPKP support
Browser blocks the site on failed validation.
8.1 HPKP: iRule
The following iRule can be used to insert HPKP header to HTTP responses
when HTTP_RESPONSE {
if { !([ HTTP::header exists "Public-Key-Pins-Report-Only “ ])} { HTTP::header insert "Public-Key-Pins-Report-Only" “<options and value>" }
}
<options and values> should be carefully reviewed, and tested as providing wrong values would lead to legitimate requests being rejected
8.2 Example:
curl -L -A "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0" -s -D - https://www.facebook.com -o /dev/null
The following iRule will enhance the security of your web application by inserting most of the headers discussed earlier in all HTTP responses sent to web clients.
I highly recommend that, if possible, when you are doing header insertion to all responses, utilize LTM policies with an 'All' match strategy. I'm currently revising my iRules to migrate over some simple functionality (Add headers, remove cookies, etc) into policies for increased performance.
I believe it is just "nosniff" without the single quotes - having the nested quotes would actually add the single quotes to the header I believe. Pascal would have to edit the article to correct that.
