A pretty common web attack involves hijacking a user’s session to get them to perform actions on your behalf.
An example attack:
Lets say Bob signs into his bank account at bank.com
From now on, whenever Bob interacts with bank.com the browser will send his cookies so that bank.com knows that the request was made by Bob.
Lets say Eve knows that he is logged into bank.com and sends him a message like:
Hey Bob,
Check out this sweet cat picture:
<img src=”https://bank.com/transfer.php?amount=10000&from=bob&t0=eve”>
Sincerely :),
Eve
When Bob loads this message, his browser will make a web request to load the image. The session cookies will be sent. But it’s not actually in image (the browser doesn’t know this), it’s a bank transfer. A bank transfer will be performed and Bob just lost all his money.
Normally you’d protect against this using csrf tokens, and use a http POST for this state changing request. See here for more information.
SameSite Cookie Flag
A new protection was recently introduced into Chrome that allows servers to instruct clients on when to send session cookies.
The problem in the bank.com CSRF attack is tricky. The browser did the right thing by trying to load the image, and it did the right thing by sending the cookies to bank.com (bank.com told the browser to always send the cookies). But the bank still failed bob. Confused deputy.
SameSite cookie flag is a way for bank.com to protect their users against this attack. When Eve sent bob the message that had the embedded image, did cookies really need to be sent to load an image? Probably not.
Using SameSite, websites can tell clients to only send cookies if the request originated from the same site.
Once you’re on bank.com it makes sense to initiate transfers. But it doesn’t make sense to initiate transfers from gmail.com or any other website. So in the previous attack example, since the transfer didn’t originate on bank.com, Bob will probably see a login page instead of a transaction receipt.
Using SameSite Cookie Flag
To set cookie, simply add the SameSite flag to the cookie like:
Set-Cookie: Session=6fa459ea-ee8a-3ca4-894e-db77e160355e; SameSite=Strict
You can specify how strict you want the SameSite restrictions to be. I’d recommend just using Strict and playing with the website for a bit, specially if you’re using a SPA.
The three options are None, Lax, and Strict. None is what a normal cookie uses. The different between Lax and Strict is mainly whether or not full page loads (like clicking on a link to bank.com) will send the cookies. Lax will send the cookies.
To read more, checkout the RFC draft. Or google it.
Some Thoughts
- How are the different types of redirects handled? If a website is using strict could I do something like http://bank.com/redirect&url?http://bank.com/deleteAcount
c0nradsc0rner 
Technically speaking: isn’t it the same as checking referer header on server site?
LikeLike
Yep! It’s essentially the browser checking Referer/Origin for you. But two small benefits come to mind:
– Origin/Referer can sometimes be missing (See Egor’s article on it: http://homakov.blogspot.com/2012/04/playing-with-referer-origin-disquscom.html) it’s a little out dated, but you get the idea. It’s pretty rare, but can happen.
– Cookies are stopped at the web request, not inspected at the server application level. Which leaves less room for programming error and less attack surface
LikeLike