If there were no cookies, websites would never know who they have in front of them. This would be pretty inconvenient for users, who would have to constantly log in to social networks, change settings on websites again and again, and lose their painstakingly compiled shopping carts in online stores as soon as they close the page. Unfortunately, the way cookies work can also be used for malicious purposes: for example, attackers can use them to impersonate logged-in users and make posts on social networks or even make online bank transfers in their names. "Such an attack is called cross-site request forgery and is not the only attack of this kind," explains Soheil Khodayari. "So-called cross-site leaks also exploit the functionality of cookies. However, they are not used to perform actions on behalf of the users, but to leak sensitive information about them."
The new SameSite guidelines are intended to prevent such attacks in the future, or at least make them significantly more difficult. But what exactly does SameSite mean, and what does it regulate? SameSite is a new cookie attribute that Google introduced in its Chrome browser back in 2016. Attributes control which properties cookies have. This includes, for example, when they expire or how large their scope is. The SameSite attribute determines whether and under what conditions cookies issued by third-party providers should be sent to first-party websites. This question arises whenever third-party services are integrated on a website, for example, in advertising, maps, login buttons, or embedded videos.
Since then, developers have been able to specify the values "strict," "lax," or "none" for the SameSite attribute. Behind these terms are clear rules on how sites handle third-party cookies. "The value 'strict' means that no cookies that do not originate from the originally visited page are allowed. 'Lax' means that cookies from other sites are only sent if users click on a corresponding link, for example, if they actively call up an embedded YouTube video by navigating to youtube.com. If developers set the attribute to 'none,' cookies are simply sent in all contexts," explains Khodayari. This was the default setting for a long time before the attribute existed and for some time after its introduction - until Google finally made "lax" the new default policy in July 2020. By now, many other browser vendors have already switched to this new default policy or are experimenting to do so, including Edge, Opera, and Firefox, for example.
Time for the crucial question: Are the users of these browsers better protected against attacks? "Yes, SameSite cookie policies are really good as a defense-in-depth. However, cross-site attacks are by no means dead," says the CISPA researcher. According to the researcher, developers need to understand how the new policies are supposed to work because otherwise, they risk implementation errors. "Our study also shows that it is possible to circumvent the new Lax-by-default policy. Moreover, in practice, they do not work against all types of requests sent between the first-party and third-party sites. "So attacks are also possible against popular websites like Tumblr, Twitch, SoundCloud, Mailchimp, and Pixiv."
The study also shows that so far, only around 19 percent of website operators of the top 500,000 pages in the Alexa ranking have given any thought to their settings and have explicitly adopted one of the three regulations. At the same time, it is precisely this active group that reveals an unfortunate trend: "The more popular the sites, the more frequently we found, the less secure setting 'none.'" Khodayari took a closer look at 211 pages that were set to the default "lax" setting to get an idea of functional losses. "About one-fifth of the requests on the pages broke due to the change. This mostly affected ads, which no longer displayed correctly, but also Like buttons and other embedded content."
Another problem with the secure implementation of the guidelines are so-called web frameworks, which are supposed to facilitate the construction of websites and are used relatively often by developers. "Even when browsers implement the 'lax' policy, what happens with 24 percent of the most popular 25 frameworks is that they silently revert the browser's Lax-by-default policy so third-party cookies are simply sent again."
Khodayari concludes, "We're already well on our way with the new policies. But things still need to happen to prevent cross-site attacks in the future more effectively. For example, SameSite policies must cover more fine-grained request contexts , and there is room for improvement in the web frameworks. In addition, we need to get the developers on board." The CISPA researcher hopes his study will provide an impetus for further improvements to SameSite policies.
If you like to learn more about SameSite policies, visit the online SameSite Cookies Wiki presented in this work: https://canopus-k.site/same-site-wiki/
translated by Oliver Schedler
