Benefits and limits of SameSite attribute

-
The SameSite attribute is a cookie flag introduced in RFC6265 with the aim to mitigate cross-site requests, such as Cross-Site Request Forgery (CSRF) attacks.

Some words about CSRF


Cross-Site Request Forgery (CSRF) is an attack that tricks a victim, that is currently authenticated to the vulnerable website, to perform unwanted actions in the contexts of the target website. Such operations usually allow the modification of the application settings and account information.
The vulnerability lies in the behaviour of browsers. In fact, browsers will automatically include session cookies while performing the HTTP request crafted by the attacker .Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish a malicious request from a legitimate one.

During over a decade of web application security, developers have adopted many techniques to mitigate this vulnerability.
The recommended prevention technique consists in including  for each HTTP request the so called anti-CSRF tokens, which are unique values, randomly generated and verified server-side.
Nowadays most of the web frameworks natively offer the support for managing the generation and verification of this security tokens.

All you need to know about SameSite attribute


SameSite cookies are a convenient way to defend against a variety of attacks that leverage cross-origin requests because they are the easiest migitation technique to deploy.

There are two values for this flag:

Strict: a cookie released with this value will not be sent along with none type of HTTP requests (i.e. POST, GET with no Top level change, GET with Top level change) originated by third party websites. Therefore, this is the most effective way to use SameSite attribute to prevent CSRF attacks.
However, this value has the downfall of negative usability impact since a user following legitimate links to other section of the hardened web application will result in a new login phase for that particular request (because session cookies have not been included by the browser).

Lax: a cookie released with this value will not be sent along POST and GET request initiated by third party website, unless the GET request causes a top level navigation change. A top level navigation change corresponds to a modification of the URL displayed in the address bar.

A quick reference table for some cases is the following:

A list of HTTP request type 

Value of SameSite that allows CSRF

link tag‘None’, ‘Lax’
form via GET action‘None’, ‘Lax’
form via POST action‘None’
iframe tag‘None’
image tag‘None’
Ajax request‘None’
Note: value 'None' corresponds to a cookie released with no SameSite attribute.

Demo for some scenarios

Let’s cover two test cases showing the situations in which Lax value does prevent CSRF and when it does not. 

Quick setup

For this purpose I will consider the dockerized version of DVWA and Burp Suite proxy.

The vulnerable section we consider in this demo

In the developer console shown above, we see that the session cookie PHPSESSID of DVWA is not released with SameSite because it is non implemented in the source code for this web application. Of course we can modify the response on-the-fly with Burp proxy and ship PHPSESSID with SameSite flag :-), see below.

SameSite=Lax; has been added in the HTTP response intercepted via proxy

Now the session cookie has SameSite attribute set with value ‘Lax’

And now everything is ready for the demo.

1. Lax value against CSRF via image tag (no Top level navigation change):
The PoC of this test case is:

<html>
  <img src="http://TARGET /vulnerabilities/csrf/?password_new=aaa&password_conf=aaa&Change=Change">
</html>

A webpage prepared by an attacker with this HTML code is visited by an authenticated victim of DVWA and as soon as he visits the crafted page, what we see outgoing from the browser is the following:

The session coookie PHPSESSID is not sent along the cross-site request

As we see, the PHPSESSID session cookie is not sent in the cross-site request. This occurs because the image tag does not cause a top level navigation change in the address bar.
Therefore, the action will fail and the SameSite cookie has denied a CSRF attack.

2. Lax value against CSRF via form GET action (Top level navigation change):
THe PoC of this test case is:

<html>
   <body onload="document.forms[0].submit();">
      <form action="http://172.17.48.226/vulnerabilities/csrf/">
         <input type="hidden" name="password_new" value="aaa" />
         <input type="hidden" name="password_conf" value="aaa" />
         <input type="hidden" name="Change" value="Change" />
      </form>
   </body>
</html>
 
The session cookie is sent along with the cross-site request

As we see, the PHPSESSID has been sent even with the SameSite attribute set to ‘Lax’.
This is because, after the execution of the above PoC, the URL displayed in the address bar is now that of the vulnerable application (a top level navigation change has taken place):

After the request the URL in the address bar has changed

Conclusion

SameSite is a quickly deployable fix that addresses an old vulnerability. However,this security attribute is not supported on all browsers (see here for current widespread). Therefore, it has to be deployed only alongside well known mitigation techniques such as anti-CSRF tokens.

Comments

Post a Comment

Popular posts from this blog

Abusing Windows 10 Narrator's 'Feedback-Hub' URI for Fileless Persistence

-
Image
Novel Accessibility Feature Abuse technique While investigating Ease of Access options in Windows 10 for new persistence techniques, I have actually found an undocumented one via 'Provide Narrator feedback' functionality. Behind the scenes the Narrator feedback consists in launching the custom handler via URI scheme ‘feedback-hub’. However, in a post exploitation scenario is possible to trivially backdoor this component with fileless payloads hosted in the registry. Even if there is no security boundary between windows logon screen and the default user desktop (indeed both part of the same window station WinSta0) the possibility of the interaction between the Narrator instance running in the environment of the locked out users and the Windows logon screen opens the chance to trigger the malicious command defined in the registry as soon as the 'Provide Narrator feedback' combination keys are pressed in the latter context. The novel technique presented in this arti...
Read more

WPA2-PSK vs WPA2-Enterprise: hacking and hardening

-
Image
This post has the aim to summarise the security aspects of WPA2, with a focus on WPA2-Enterprise hacking. At the end, EAP-TLS is presented as a pretty secure implementation. WPA2 in brief The Wi-Fi Protected Access is a wireless technology designed to secure the communiciations between stations and the Access Point from eavesdropping and tampering attacks. It is defined in 802.11i standard and has been adopted in home, small business (WPA2-Personal) and enterprises (WPA2-Enterprise) since 2004.  The WPA2 implementation is based on the 4-way handshake. The PMK (pairwise master key) is the value that both station and AP know and from which the PTK (pairwise transient key) is calculated and valid for the session. The station MAC, the AP MAC and two nonces (A-Nonce, S-Nonce) that are exchanged during the 4-way handshake are also part of the PTK generation process. From an offensive point of view, capturing the messages of the 4-way handshake that are tr...
Read more

Management Frame Protection and its limitations

-
Image
In this article we talk about management frames, their exposure to Denial of Service (DoS) via de-authentication attack, how Management Frames Protection can prevent this and its limitations against other DoS attacks discovered during the years by security researchers. A brief overview of Management Frames Management frames are at the centre of the WLAN operability and also have an important role in the negotiation activity between an access point and its stations. Code Field (Wireshark filter) Subtype 0x00 Association Request 0x01 Association Response 0x02 Re-Association Request 0x03 Re-Association Response 0x04 Probe Request 0x05 Probe Response 0x06 Reserved 0x07 Reserved 0x08 Beacon 0x09 ATIM 0x0a Disassociation 0x0b Authentication 0x0c Deauthentication 0x0d A...
Read more