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: https://mikewest.github.io/cookie-incrementalism/draft-west-cookie-incrementalism.html 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”.
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
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.
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.
NICE DCV has this documentation on embedding their web client in an iframe: https://docs.aws.amazon.com/dcv/latest/adminguide/embed-in-iframe.html
In a related fix, bug 8192, the SameSite attribute for cookies was explicitly set to Lax to align with modern browser behaviour and improve cross-site request security. This change was made to ensure predictable cookie handling and will prevent embedding Web Access in an iframe.
In bug 8400 we started sending the Content-Security-Policy header with the directive frame-ancestors set to 'none'. This was done to quiet security scanners complaining about the fact that we don't send it. This header completely blocks Web Access and Web Administration from running inside an iframe. When we want to allow embedding of our web services, we need to consider a setting "allow_embedding" that, when enabled, sets "SameSite=None" and "Content-Security-Policiy" to something else.
The header “X-Frame-Options: DENY” is now also sent as part of bug 8400, similarly to “Content-Security-Policy: frame-ancestors”, and “SameSite=None” it also blocks Web Access from working when embedded.
