Support sandboxed iframe

[DeepDiver1975]

Describe the Bug

Collabora Online cannot be used inside a sandboxed iframe because collabora tries to access the parent document.
See screenshots below for further details

Steps to Reproduce

1. load Collabora in <iframe sandbox="allow-scripts">
2. see it failing

Expected Behavior

Shall load

Actual Behavior

Does not load

Screenshots

Desktop

• Collabora version: image: collabora/code:23.05.5.2.1
• OS and version: Debian 12
• Browser and version: Chromium 124.0.6367.60

Additional Context

ocis docker setup as per https://github.com/owncloud/ocis/tree/master/deployments/examples/ocis_wopi

[meven]

Regarding allow-same-origin, it is required currently for:

• localstorage accessing and reading, user's settings
• localization is loaded using XHtmlRequests

For localization this could be changed.
For localstorage, this would require to read and pass to the host window those settings.

Using sandbox="allow-same-origin allow-scripts" is already an isolation improvement, but COOL does not work properly in those conditions.
I am looking into it.

[meven]

Regarding allow-same-origin, it is required currently for:

* localstorage accessing and reading, user's settings

* localization is loaded using XHtmlRequests

For localization this could be changed. For localstorage, this would require to read and pass to the host window those settings.

Using sandbox="allow-same-origin allow-scripts" is already an isolation improvement, but COOL does not work properly in those conditions. I am looking into it.

Using allow-scripts allow-same-origin allow-downloads allow-popups for sandbox allows CODE to work properly.

[DeepDiver1975]

Yes - but from a security perspective I don't want to grant an application allow-same-origin.

Under the assumption that the ifamed application is compromised by a vulnerability if can leave the iframe and also attack the parent application.
Any interaction between these two applications should happen using Window.postMessage() - see https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage

[meven]

Yes - but from a security perspective I don't want to grant an application allow-same-origin.

I understand, and Collabora Online could support it with some efforts.
allow-same-origin is a lot more restrictive that just communicating with the parent frame.

Collabora Online already uses only postMessage to communicate with the parent frame.
But without allow-same-origin, indeed Collabora Online is a potential attack vector.

[meven]

An option on your end, is to host Collabora-online on a host with a different domain (or just port difference).
That would restrict access from the iframe to the parent application, making it a cross-domain iframe.
That might not be easy to accommodate on your end though.

[mmeeks]

Question is - where are we not using post-message? there is that frame resizing thing; @meven do we have a short list of things to fix that get this wrong ? =)

[meven]

Question is - where are we not using post-message? there is that frame resizing thing; @meven do we have a short list of things to fix that get this wrong ? =)

• localstorage, and how to persist user settings.
• localization data, we use a XHR request to fetch them, that can't work
• the nested iframe to detect resizing, could be replaced with a ResizeObserver

I have a POC branch of Collabora Online with localstorage turned off, localization off and without the resize iframe that runs in Firefox (but not chrome) and firefox has presentation restriction (even with a allow-presentation).

[meven]

The _fileDownloader iframe could also be replaced either with a "<a download" or window.downloads.

[meven]

I have tested the clipboard and it seems affected for complex pasting (but that might another issue).

I have made a branch that has a few features turned off as a baseline to test COOL with sandbox="allow-scripts allow-presentation allow-downloads allow-popups" :

https://github.com/meven/cool-online/tree/meven/iframe-sandboxed

The missing features are the welcome window, l18n, presenting in window is broken and full-screen not-working.

Apart from that, I haven't noticed any problems.

Some compatibility changes are missing (replacing im Map.js the _fileDownloader and _resizeDetector by other means (a download, and ResizeObserver ) that can already be made in master.

[mmeeks]

Getting a new server-side setting storage API implemented is really a larger task if we can't use the browser setting storage; this is a longer term task I think.