SameSite Cookie attribute?
December 4th, 2017, Updated April 1st, 2019 (fixing demo page)
Introduction
The last decade I was teaching my students the five cookie attributes: “path, domain, expire, HttpOnly, Secure”. But now we have another — SameSite. Do you know the details of the newly introduced SameSite cookie attribute? A new http security feature preventing cross site request forgery. The value can be set to Strict or Lax.
Example with SameSite:
Set-Cookie: jsessionid=oIZEL75SLnw; HttpOnly; Secure; SameSite=Strict
If not, please read this brief intro and follow the little quick and dirty demo for your reference. Please make sure you do the demo with Firefox and Chrome or your other preferred browser. Compare the results. Use the developer tools for observing the network stack.
Definition by OWASP
SameSite prevents the browser from sending the cookie along with cross-site requests. The main goal is mitigating the risk of cross-origin information leakage. It also provides some protection against cross-site request forgery attacks. Possible values for the flag are Lax or Strict.
Example Use-Case
Let’s assume you have an e-banking web site and the transaction form is prone to the cross-site-request-forgery vulnerability. Let’s assume the e-banking customer (victim) is already authenticated (cookie) and the attacker motivates the victim to click on a xsrf link that would create an illegal transaction behind the scene. Such an xsrf link could be advertised by e-mail, Twitter, Facebook, a public blog or any other HTML based system. A modern and secure e-banking solutions would protect against this type of attack using a random xsrf token. But for the sake of this article, let’s assume the e-banking is vulnerable and does not contain such a random xsrf token.
Before SameSite, the authenticated victim clicking on the prepared xsrf page would then execute the transaction. This is, because the browser has a session cookie with the e-banking and would therefore add the session cookie to the e-banking transaction request. But what if the browser would not add the session cookie? This is exactly what SameSite does. A browser is not adding the cookie (session) to an already authenticated web site, if the link derives from an external site. In case of SameSite=Strict, the browser will NOT ADD the cookie in general. If SameSite=Lax, the browser is sending the cookie if the user clicks on a top level URL. Do the demo below and understand the difference between Strict and Lax.
Demo Page
I created a brief demo page for the sake of the SameSite cookie attribute. It consists of two web sites. The first page is setting some cookies and the second is requesting an URL from the first site. Thus, you can now test with Firefox, Chrome or Safari if the cookies are sent to first page.
Testing with Chrome
Step 1: Visit the first demo page
First, you need to load the first demo page that is setting four different cookies. The cookies will be set using the Apache web server built-in mod_headers syntax.
Please check if the cookies have been set in Chrome. Use the builtin developer tools in the “Application” tab. See the image below.
Cookie MyBamBut without SameSite attribute (as it was the last 10 years)
Cookie MyBamButNone with SameSite=None
Cookie MyBamButStrict with SameSite=Strict
Cookie MyBamButLax with SameSite=Lax
For me, Chrome was accepting three of four cookies. The cookie that has SameSite set to None was rejected.
Step 2: Review the HTML code of the second demo page
As you can see, the second page is having a top level URL (the a href) that points to the first page and additionally is loading an image as <img src> from the first page. I must admit, there is no image on the first page, but this does not change how the browser behaves. It is just an extremely simple way of having something referenced from the first page.
Step 3: Visit the second demo page
Please visit the second demo page with the same Chrome browser you did step 1 and step 2. We want to see what cookies will be sent along to the first demo page. Open the developer tools, click on “Network” and reload the page. Please *DO NOT* click on “printheaders.php” in this step. Make sure you are only reloading (not clicking on any link) and check which cookies will be sent by Chrome. Analyze the Request Headers.
Feedback by Rafał Podlipny: In latest chrome cookies sent from the second site was not shown in network tab. Here is explained why, and how to bring it back (at one’s peril).
As you can see in the picture above, Chrome is only adding the cookie without the SameSite attribute set. The SameSite=Strict and SameSite=Lax cookies were not sent to the first demo page. Cool — this is what you want. A cool xsrf protection.
Step 4: Follow the link in the second demo page
Now let’s see how Chrome behaves if you click (this is different than just reloading from the step above) on the top level link. Therefore, please click on the PrintHeaders link on the second demo page and analyze the Request Headers again as in step 3.
In the picture below you can see what Cookies have been sent to the first demo page when clicking on a top level URL.
Chrome added MyBamButLax to the HTTP request to the first demo page. But the MyBamButStrict has never been sent to the first demo page. Thus, setting SameSite=Strict is really denying xsrf attacks.
Conclusion
The SameSite cookie attribute is a great help against cross site request forgery. Setting the value to Strict will prevent (newer) browsers to add the cookie if the link is originated from something different then the origin site. This is extremely cool in a e-banking environment.
But keep in mind possible drawbacks. If you have your company wiki page that links to your company SAP portal, you Social Media platform or to other company websites, the SameSite=Strict would probably not being accepted by your user base. Users would complain that they cannot use wiki links any more and must re-authenticate whenever they use the wiki portal.
Furthermore, the SameSite attribute is not yet implemented in all major browser versions. As of November 2017 the SameSite attribute is implemented in Chrome, Firefox, and Opera.
Thank You
Thank you for reading. Was my pleasure to setup a demo page with SameSite and I hope this demo helps others understanding the impact of SameSite.
Regards, Ivan Bütler
CEO Compass Security
www.compass-security.com
Acknowledgement
Special Thanks to Rafał Podlipny. The demo page was setting the cookies using the html meta tag (I was lazy at the time of writing the original article).
Unfortunately Chrome since v. 65 does not longer support setting cookie by <meta> tag… You could modify the article to warn readers about it, or rewrite setting cookies to javascript (which involves additional friction for the reader to understand the topic).
That’s why I changed the demo and I am using now the Apache mod_headers approach for setting the cookies. This should work in Firefox, Chrome and any other browser. Thank you!
