cancel
Showing results for 
Search instead for 
Did you mean: 
Login & Join the DevCentral Connects Group to watch the Recorded LiveStream (May 12) on Basic iControl Security - show notes included.
Nir_Zigler_7297
Altostratus
Altostratus

The recently disclosed groundbreaking vulnerabilities have set a precedent for how massive a security vulnerability can be. In the recent years, we have witnessed vulnerabilities that affect major frameworks like Java, PHP, OpenSSL and CGI. We haven’t seen a vulnerability affecting such a fundamental hardware piece in our computers – the CPU – until this day.

These vulnerabilities shuffle the cards on all the conventional protection mechanisms that exist in the web today – Same Origin Policy, Cross-Origin Source Sharing, Content Security Policy, et al.

The system memory, and IPC (Inter-Process Communication) were considered safe until today, so we could rely on sensitive data residing in memory not leaking outside.

Now that the picture has changed, it forces us to think about new attack surfaces. For example, an attacker may host a malicious website that scans the browser memory for data from other websites. If a victim website is still open in another tab, the data on that page may be compromised.

Reducing the Attack Surface with “SameSite” Cookie Attribute

In order to mitigate some specific attempts of extracting private data, we could consider using the following method.

“SameSite” cookie attribute – This attribute, which is already supported by the major browsers, will prevent the browser from sending the cookie in any request which didn’t originate from the same domain. An attacker that would like to “spray” the memory with private data of the victim site could simply create an website that invokes requests or includes iframes pointing to that site. Regardless of the “SameSite” cookie attribute, the attacker would not be able to read the response contents thanks to the SOP (“Same Origin Policy”) mechanism. However, in light of the new vulnerabilities, this trick could result in sensitive data being stored in memory which then could be read by the attacker’s malicious JavaScript.

Enabling the “SameSite” cookie attribute will prevent the attacker from controlling authenticated/sensitive data being saved in the memory (no cookie = no session).

SameSite attribute is controlled in: Security  ››  Application Security : Headers : Cookies List  ››  Edit Cookie  ››  Insert SameSite Attribute

0151T000003d786QAA.PNG

Comments
Mike_Maher
Nimbostratus
Nimbostratus

What version of Big-IP is this feature available in?

 

dgytech
Altostratus
Altostratus

I am running 11.4.0 (Build 2464.0) and do not have this option. What version is this available in?

 

Avalanchee
Nimbostratus
Nimbostratus

Thank you for your interest. This is a new feature available in version 13.1.0 and up.

 

Gordon_33457
Nimbostratus
Nimbostratus

Is there a way to set SameSite=Lax using the HTTP::Cookie command in an iRule?

 

Avalanchee
Nimbostratus
Nimbostratus

Unfortunately the HTTP::Cookie command doesn't support the SameSite flag. If support was to be added, it would be included in versions past 13.1.0 - which would make it obsolete for the issue at hand (since this feature is included in ASM since 13.1.0).

 

The best way to have this enabled using an iRule would be to rewrite the Cookie header using string search and replace.

 

You would have to capture responses from the web server, search for the following header: "Set-Cookie: my_cookie=abcd;" and rewrite it as: "Set-Cookie: my_cookie=abcd; SameSite=Lax"

 

Hoolio
F5 Employee
F5 Employee

In BIG-IP v12.0, we added the ability to use "HTTP::cookie attribute" to read/set/delete arbitrary cookie attributes. Here is an example for how to use this command to set the SameSite attribute on BIG-IP and web application cookies:

 

https://devcentral.f5.com/s/articles/iRule-to-set-SameSite-for-compatible-clients-and-remove-it-for-incompatible-clients-LTM-ASM-APM

 

In v11, you can use Avalanchee's suggestion of appending ; samesite=VALUE to Set-Cookie response headers. There's an example of this in the Devcentral iRule toolbox: https://github.com/f5devcentral/irules-toolbox/tree/master/security/http/cookies

 

Aaron

Version history
Last update:
‎11-Jan-2018 07:39
Updated by:
Contributors