SameSite and XSSI
What is here:
- SameSite cookie
Short review of
<meta http-equiv="<>" content="<>">
The http-equiv attribute provides an HTTP header for the information/value of the content attribute.
The http-equiv attribute can be used to simulate an HTTP response header.
So, basically, using a HTML directive like:
<meta http-equiv="set-cookie" content="id=12345; SameSite=Strict">
is equivalent to:
Set-Cookie: id=12345; SameSite=Strict;
sent by the server.
The aims of this cookie attribute are:
prevent cross origin timing attacks:
prevent cross origin script inclusion (XSSI):
“XSSI is a fancy way of saying: you are including in your program, someone elses code; You don’t have any control over what is in that code, and you don’t have any control over the security of the server on which it is hosted.
If my mate dave, then decides to put something malicious in his cool widget (say, a sniffer/keylogger that sends all the user’s cookies, form data and keypresses to his server) then I won’t necessarily know. Also, the security of my app now depends on the security of dave’s server. If dave’s server gets compromised and coolwidget.js is replaced by the attacker, i again won’t necessarily know and the malicious code will run as part of my app. “(https://stackoverflow.com/questions/8028511/what-is-cross-site-script-inclusion-xssi)
prevent CSRF: SameSite cookies are only sent if the site the request originated from is in the same origin as the target site (in strict mode for GET and POST, in lax mode only for POST requests).
NOTE: The cookies are, as also with cross-site request forgery (CSRF), included when requesting a resource from a different host.
SameSite cookie flag can be
- strict: will prevent the cookie from being sent by the browser to the target site in all cross-site browsing context. A bank website however most likely doesn’t want to allow any transactional pages to be linked from external sites so the strict flag would be most appropriate here. It can affect negatively the user experience, if a user click on a FB profile page on a site diverse than facebook.com he will see error 404.
- lax: the browser is sending the cookie if the user clicks on a top level URL
Set-Cookie: CookieName=CookieValue; SameSite=Lax; Set-Cookie: CookieName=CookieValue; SameSite=Strict;
Let’s make some examples:
Many times the browser will send some requests cross origin when the page is loaded, could it be advertisements, tracking, analitycs, Facebook like buttons and so more. Along with these requests, the cookies present in the victim browser that belong to that domains will also be sent.
This is how Third-Party can track their users.
With SameSite lax only TOP LEVEL NAVIGATION allow requests to include cookies.
Basically, they don’t change the URL in your address bar. Because these GET requests do not cause a TOP LEVEL navigation, thus cookies set to Lax won’t be sent with them.
Should i use GET or POST?
- When the parameters are carried by GET, they stay in the browser history. They also will be placed in server logs and the Referrer header in the request made toward third parties.
- Another reason for not using GET requests is that cookies set to Lax are still sent along with GET requests, giving attackers another opportunity to exploit users.
- Lastly, exploiting a CSRF vulnerability by using GET is much easier. To exploit a CSRF vulnerability in a form using GET, an attacker does not have to own a site. He can inject this payload into a forum message, post comment or image tag.
GOOD reference for SameSite explanation → https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/
Problems with SameSite
Blocking all third party cookies could make the browser experience very poor.
Setting the "SameSite" attribute in "strict" mode provides robust defense in depth against CSRF attacks, but has the potential to confuse users unless sites' developers carefully ensure that their session management systems deal reasonably well with top-level navigations. Consider the scenario in which a user reads their email at MegaCorp Inc's webmail provider "https://example.com/". They might expect that clicking on an emailed link to "https://projects.com/secret/project" would show them the secret project that they're authorized to see, but if "projects.com" has marked their session cookies as "SameSite", then this cross-site navigation won't send them along with the request. "projects.com" will render a 404 error to avoid leaking secret information, and the user will be quite confused. Developers can avoid this confusion by adopting a session management system that relies on not one, but two cookies: one conceptualy granting "read" access, another granting "write" access. The latter could be marked as "SameSite", and its absence would provide a reauthentication step before executing any non-idempotent action. The former could drop the "SameSite" attribute entirely, or choose the "Lax" version of enforcement, in order to allow users access to data via top-level navigation.
Differences between XSSI and XSS? Read here