Comment 1 Madeleine 2024-10-07 11:31:58 CEST

The SameSite attribute for cookies is an optional security feature to control how cookies are sent with cross-site requests, helping to prevent attacks like cross-site request forgery (CSRF). When a cookie is set with a SameSite attribute, it tells the browser under what circumstances the cookie should be sent using one of three values:

- SameSite=None: Cookies are sent with all cross-site requests. If this is used, the cookie must also be set as Secure, meaning it will only be sent over HTTPS connections.

- SameSite=Lax: Cookies are generally not sent with cross-site requests, but they can be sent when the user navigates to your site from an external link (such as clicking a link from an email or another website).

- SameSite=Strict: Cookies are only sent with requests from the same site that set them. They are not sent with any cross-site requests, even if the user is navigating to your site from a different one. 

In the document referenced in comment 1, it is explained that browsers have changed their default behaviour for cookies without an explicit SameSite attribute. Previously, such cookies were treated as SameSite=None, but now they usually default to SameSite=Lax. However, this behavior varies between browsers, and some may display a warning when a cookie is sent with cross-site request without an explicit SameSite attribute. To ensure predictable behavior across all browsers, we should explicitly define the SameSite attribute in our cookies.

Comment 2 Madeleine 2024-10-07 12:59:39 CEST

To test the behaviour of the cookies in Web Access during a cross-site request, Web Access was embedded in an iframe. When attempting to log in, the error message 'Failed to connect to server' appeared. In the 'agent' request, it was observed that a response cookie without a SameSite attribute was blocked. When this cookie was sent with SameSite=None, additional cookies were also blocked, resulting in the error message 'no VNC password given by server' during login. However, when all cookies were sent with SameSite=None, it was possible to log in to Web Access via the iframe.

Additionally, testing with cookies set to SameSite=Lax showed the expected behavior, where the cookie was blocked and login was prevented. In Firefox, the following message appeared next to the cookie, confirming that the attribute worked as expected: 'This attempt to set a cookie via a Set-Cookie header was blocked because it had the "SameSite=Lax" attribute but came from a cross-site response which was not the response to a top-level navigation.'

The attribute SameSite was also set to Strict to verify that it worked as expected and to ensure that it did not affect the regular functionality of Web Access, which continued to operate as usual.

Comment 3 Madeleine 2024-10-07 14:46:33 CEST

I chose to send cookies with SameSite=Lax because this already is the default behavior in many browsers. This minimizes the risk of breaking existing functionality while still providing a reasonable level of security. Also tested in visiting the embedded Web Access using Microsoft Edge and Firefox, works as expected.

Comment 5 Emelie 2024-10-08 15:02:06 CEST

We agree with the usage of SameSite="Lax" vs SameSite="Strict" since it provides enough security and minimizes changes in behaviour. The goal with the bug was to be more consistent and not more secure, which this achieves.

The code looks good. There are minor comments on input validation in the send_cookie function and how it is called regarding default arguments.

Reopening for the code fixes.

Comment 7 Samuel Mannehed 2024-10-10 12:15:52 CEST

The code comments have now been fixed.

Comment 8 Samuel Mannehed 2024-10-10 12:55:39 CEST

We tested that things work as expected using RHEL 9. An old build without the same-site fix (build 3721) and a recent one (build 3728) were compared. The behavior was tested on the following browsers:

* Chrome 129 on Fedora 40
* Firefox 131 on Fedora 40
* Microsoft Edge 129 on Windows 11
* Safari 18 on macOS 15

When comparing, we used a simple HTML document with Web Access embedded in an <iframe>. Note that, before being able to test, we had to visit Web Access normally to add a trust-exception for the self-signed certificate.

On all the above browsers, we saw the same behavior before and after the changes. Both using build 3721 and build 3728, we were unable to connect using an embedded Web Access. The error we got was “Failed to connect to server”.

That is expected, since the default value in modern browsers is “SameSite=Lax”. This change isn't meant to have an impact on the functionality, given that the user is using a modern web browser.

However, in the browser's developer-tools, we could see a difference. We looked at the network tab, and the “agent”-request. On the details for that request, there is a tab called “Cookies”:

 * With build 3721, in Chrome, Edge and Safari we saw that SameSite was
   unset, but in Firefox there was no SameSite-field. In Chrome, a number of
   warnings were printed in the console:

> Chrome is moving towards a new experience that lets people make an informed choice with respect to third-party cookies.

 * With build 3728, all tested browsers showed that SameSite was set to
   “Lax”. And the warning about “third-party cookies” that Chrome printed
   was gone.

Lastly, we attempted to find an old browser that would allow us to test the behavior of a browser that doesn't have this new SameSite default behavior. We checked all the machines in our lab and started a SLES 15 VM, but in all cases both the Chromium and Firefox versions were too modern. The oldest we could find was Chromium on IGEL OS 12, which was version 115, but that's still from 2023.

Given that we were unable to find a platform with an old browser, we assume that our users will also be using modern browsers. With that assumption, we decided that it wasn't worthwhile to investigate further.

All good! Closing.