Bug 8191 - It's no longer possible to run Web Access in an iframe
Summary: It's no longer possible to run Web Access in an iframe
Status: NEW
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Web Access (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: LowPrio
Assignee: Bugzilla mail exporter
Depends on:
Reported: 2023-07-13 12:48 CEST by Pierre Ossman
Modified: 2024-03-12 13:38 CET (History)
1 user (show)

See Also:
Acceptance Criteria:


Description Pierre Ossman cendio 2023-07-13 12:48:34 CEST
Users may want to embed a login to ThinLinc inside one of their other web pages using an iframe. Unfortunately, that is starting to break, at least if the containing page and Web Access are on different sites (in HTTP same-site terminology).

What happens is that the WebSocket connection failed, and the user is greeted with:

> Failed to connect to server

This is because the browsers are changing their default cookie behaviour in accordance with this suggestion:


In short, cookies are no longer included in every request to the site that issued them. Instead, they are only included when the page loading the resource is the same site as the resource.

Unfortunately for us, this also covers iframe usage, as the browser considers the container page to be the page loading things, not the Web Access page inside the iframe.

And without our auth cookie, the WebSocket connection fails.

Chrome has already implemented this, and will print the following under "Issues":

> Indicate whether a cookie is intended to be set in a cross-site context by
> specifying its SameSite attribute

Firefox is going to implement it, and currently warns:

> Cookie “auth_cookie” does not have a proper “SameSite” attribute value. Soon,
> cookies without the “SameSite” attribute or with an invalid value will be
> treated as “Lax”. This means that the cookie will no longer be sent in third
> party contexts. If your application depends on this cookie being available in
> such contexts, please add the “SameSite=None“ attribute to it. To know more
> about the “SameSite“ attribute, read
> https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite

If we explicitly set "SameSite" to the new "Lax" default policy, then Firefox also breaks:

> Cookie “auth_cookie” has been rejected because it is in a cross-site context
> and its “SameSite” is “Lax” or “Strict”.
Comment 1 Pierre Ossman cendio 2023-07-13 12:49:14 CEST
There is also an issue if the containing site uses http instead of https:

> ThinLinc Web Access encountered an error:
> The operation is insecure.
> https://lab-95.lkpg.cendio.se:300/app/webutil.js
> readSetting@https://lab-95.lkpg.cendio.se:300/app/webutil.js:159:9
> start@https://lab-95.lkpg.cendio.se:300/app/ui.js:94:21
> prime/<@https://lab-95.lkpg.cendio.se:300/app/ui.js:49:27
> promise callback*prime@https://lab-95.lkpg.cendio.se:300/app/ui.js:47:39
> @https://lab-95.lkpg.cendio.se:300/app/ui.js:1758:4
Comment 2 Pierre Ossman cendio 2023-07-13 13:01:18 CEST
The most obvious way to fix this is to set "SameSite" to "none", which effectively gets us back to our previous behaviour.

The question is if we want this new protection the browsers give us. And related, do we want to have even more blocking of iframes to prevent attacks such as clickjacking?

There (expectedly) are no obvious security issues going back to the old model. The containing page JavaScript cannot access the iframe's cookies, and the cookie is limited to only be included for the correct WebSocket URL.
Comment 3 Pierre Ossman cendio 2023-07-13 13:04:31 CEST
Note that even with that fix, some browsers might still block third-party cookies, depending on privacy settings.

We may want to have an explicit check for things to give a better user error message.
Comment 6 Pierre Ossman cendio 2023-09-28 09:39:37 CEST
NICE DCV has this documentation on embedding their web client in an iframe:


Note You need to log in before you can comment on or make changes to this bug.