SameSite Cookies: Are They Still a Risk?

G5 Cyber Security

1 week ago

TL;DR

Yes, SameSite cookie vulnerabilities can still be present today if not implemented correctly or if older browsers are supported. While modern browsers have good support for Secure and SameSite attributes, misconfiguration or lack of consistent application across your entire domain remains a problem. This guide explains how to check for issues and fix them.

1. Understanding SameSite Cookies

SameSite cookies are an important cyber security measure designed to prevent Cross-Site Request Forgery (CSRF) attacks. They control when cookies are sent with cross-site requests. There are three main values:

Strict: The cookie is only sent for requests originating from the same site as the cookie was set. This offers the best protection but can break legitimate cross-site functionality.
Lax: The cookie is sent with same-site requests and top-level navigation GET requests (e.g., clicking a link). A good balance between security and usability.
None: The cookie is sent with all requests, regardless of origin. Requires the Secure attribute to be set if used; otherwise, it’s ignored by most browsers.

2. Checking Your Cookie Attributes

You need to verify how your cookies are configured. Here’s how:

Browser Developer Tools: The easiest way is using your browser’s developer tools (usually accessed by pressing F12).

Go to the Application or Storage tab.
Find the cookies associated with your domain under Cookies.
Inspect each cookie’s attributes: Domain, Path, Secure, and SameSite.

Command Line (using curl): You can also use command-line tools to inspect cookies.

curl -v https://yourdomain.com/somepage

Look for the Set-Cookie header in the output. It will show you the cookie attributes.

3. Identifying Potential Vulnerabilities

Here are common issues to look for:

Missing SameSite Attribute: Cookies without a SameSite attribute are treated as Lax by many browsers, but older browsers may send them with all requests, making you vulnerable.
Incorrectly Set Secure Attribute: If SameSite=None is used, the Secure attribute must be present and set to true. Otherwise, the cookie will likely be ignored.
Inconsistent Application: Some cookies might have correct attributes while others don’t. Ensure all session cookies are consistently protected.
Subdomain Issues: Check if cookies are correctly scoped across subdomains. The Domain attribute needs to be set appropriately.

4. Fixing SameSite Vulnerabilities

Set the SameSite Attribute: For most applications, SameSite=Lax is a good starting point. If you need cross-site functionality, carefully consider using SameSite=None with Secure.
```
Set-Cookie: sessionid=abcdefg; Domain=yourdomain.com; Path=/; SameSite=Lax; Secure
```
Ensure Secure Attribute is Present for None: If using SameSite=None, always include the Secure attribute.
```
Set-Cookie: sessionid=abcdefg; Domain=yourdomain.com; Path=/; SameSite=None; Secure
```
Update Your Code: Modify your server-side code (e.g., PHP, Python, Node.js) to include the SameSite attribute when setting cookies.
Example (PHP):
```
setcookie('sessionid', 'abcdefg', ['samesite' => 'Lax', 'secure' => true]);
```
Test Thoroughly: After making changes, test your application in different browsers (including older versions) to ensure functionality isn’t broken and cookies are behaving as expected. Use the developer tools described earlier.
Content Security Policy (CSP): Consider using a Content Security Policy to further mitigate CSRF risks by controlling which resources your browser is allowed to load.

5. Supporting Older Browsers

Older browsers may not fully support the SameSite attribute. You might need to consider alternative mitigation techniques for these users, such as:

Double Submit Cookie Pattern: This involves setting a random value in both a cookie and a hidden form field.
Synchronizer Token Pattern (STP): Similar to the double submit cookie pattern but uses a token instead of a random value.