Cookies have been an integral part of the internet since the early 1990s, but excessive use of these text files presented vulnerabilities used to perform malicious activity, mainly cross-site-request forgery (CSRF) attacks. CSRF exploits based on cookie vulnerabilities are mainly from the way cookies are sent with every server request from the user’s browser. To fight this vulnerability, browser designers offer the new “SameSite” attribute that stops cookies from being sent to third-party applications during a server request. The SameSite attribute should be used in new web development for every cookie that contains user data.
Basics of Cookie Functionality
Before getting into the way SameSite works, you should first understand the way cookies work when making requests to a server. Cookies have long been a way for web developers to persist data across requests without storing them on the server. Developers can create a cookie file on a user’s browser, which is stored in the browser’s directory on the user’s device. When requests are made to the developer’s server, any cookies created on the developer’s domain are sent with the request.
For example, suppose you have a cookie that stores user preferences settings. The user chooses to view the site in dark mode, and a cookie tells the web server to always display content using a dark mode theme for this user. For every request sent to the web server, this cookie is sent. Using browser developer tools, you can see cookies sent with every request header.
Now, suppose that another website owner decides to embed an image from your site into their own site layout. This method of displaying images is considered “bandwidth leeching” or “hot linking,” but it’s a legitimate way to display content from another site. When users access this third-party site with your embedded image, the cookie is sent to the server. When a request is made for the embedded resource, the cookie is sent to the third-party server as well as yours. The user’s browser retrieves your resource and displays it in the third-party web page.
To summarize what happens when a third-party site requests resources on your site, consider site a.com (the third-party site with your images embedded) and b.com (your site). A user makes a request to a.com, and the following happens:
The browser sends a request to a.com with all cookies for a.com.
The browser sees the embedded image must be called from b.com, so any cookies are included with the request.
Site a.com takes the request for b.com images and sends it to b.com along with the necessary cookies. This request has the REFERER header added to it, and this header tells b.com that a request has been made from another website to retrieve images.
The user’s browser displays your images with any preferences set up by the cookie settings.
This method of retrieving third-party assets is how many current applications work. For instance, many website owners use YouTube to embed videos into local content. When you view the video, a cookie determines if you have already seen some of the video content and allows you to return to the place where you stopped the video.
Cookies and CSRF
Now that you know cookies are sent with third-party requests, you can understand how this browser loading behavior can be dangerous for viewers. What if the cookie contains sensitive information? For instance, cookies can be used to keep a user authenticated into a system. This cookie might have the user’s account credentials included, and this allows an attacker to see them and use them for nefarious purposes.
As an example, an attacker could take the cookie’s value and use it to submit actions to another server. Site credentials should never be stored in cookies, but developers with poor cybersecurity habits could store usernames, passwords, and other information in a cookie. With this information, an attacker can perform actions in the context of the user account. Identities can be stolen, unintended actions can be taken such as sending money to an attacker, and many other CSRF activities are possible with this vulnerability.
The SameSite Attribute
A new initiative lets web developers set the SameSite attribute on cookies. The SameSite attribute has three values: Lax, None or Strict. If the attribute is not set at all, the Lax value is set as the default, but if SameSite is set as None the developer must use the Secure attribute which ensures that the cookie will only be used in HTTPS requests.
With the Strict value, the cookie will only be sent if the request is made to the same site where the resource is located. This means that any requests for embedded resources will not include the cookie for the main site. In the example of site a.com and b.com, if a.com embeds resources from b.com, b.com’s cookies will not be included in requests to a.com.
The None configuration will allow sites to embed resources and share cookies. The cookie should be sent only with the Secure attribute, meaning it will only be sent when a secure protocol is used, which is typically HTTPS. None and Lax should only be used when cookie values are not sensitive and having these cookies be sent to a third-party poses no cybersecurity threat.
If you need cookies sent for your website to function properly, you can use the Lax setting. The Lax configuration allows cookies to be sent and forwarded from third-party sites, and they can be sent over HTTP or HTTPS. By using Lax as the default, browsers have backwards compatibility with older sites that do not have the SameSite attribute set.
Future Web Development Projects
For web developers, the SameSite attribute should be considered when creating sites that work heavily with cookies. Even with the Strict configuration is used, developers should still never store sensitive information in a cookie. This information could be stolen from the user’s account and later used in a variety of attacks including CSFR, XSS (Cross-Site Scripting), and other impersonation methods. Using SameSite, many of today’s vulnerabilities involving CSRF and cookies can be remediated and user accounts and private data is kept safe.