tildeio
Preventing direct access to standboxed content
This is more of a questions than a bug. What prevents users from just directly accessing the standboxed content is these examples? For instance:
//mydomain.com/samples/profile_viewer/profile_viewer.html
If a user clicks on a link to that, the widget author can now get that user's cookies. Is the idea to send server content in some other manner where direct access is impossible? Does this preclude allow users to write widgets that have multiple files?
I understand the workaround is to host user generated content on a different domain, but this eliminates one of the perks of oasis.js.
You can't host untrusted/user-generated code on a domain with sensitive cookies. In a secure oasis deployment, the container, as well as each card, would be hosted on distinct domains.
@tristanz As long as the sandbox attribute isn't supported by all browsers, you would need to host the card/widget on a "safe" domain as @lukemelia mentioned.
@Cyril-sf didn't you add a allow-same-origin polyfill that causes unsupported browsers to break if they can't sandbox properly?
@tarcieri Correct, Oasis.js will complain if you try to host the card on the same domain. See https://github.com/tildeio/oasis.js/blob/b657d0d3b3814e8b7fa264cf86c19d8cffe61f17/lib/oasis/iframe_adapter.js#L10-L28
I wasn't sure about the use case for same origin support with url source even on browsers that support sandbox attribute. In the example, http://example.com/profile_viewer.html can presumably be accessed directly, not just via the sandboxed iframe. I was wondering (hoping) that you'd found a workaround to this issue to prevent direct access. I'm aware of any browser features that allow that though.
@tristanz on browsers that implement <iframe sandbox> correctly, its use should result in the sandboxed content receiving a unique origin even if content is loaded from the same origin as the outer page, unless you specify the allow-same-origin capability, or at least that's my understanding.
The code @Cyril-sf linked should ensure that browsers which don't properly sandbox content break rather than loading the content insecurely.
@tarcieri that's my understanding. The problem is that the insecure content is almost always accessible directly as well, which makes same-domain sandbox not so useful. All you need is for a user to click on the direct URL and that content can steal the cookie. You'd need to prevent direct access, which is in most cases not easy. It is sometimes possible, for instance if you use srcdoc.
@tristanz in that case, use CSP to ensure that scripts from the untrusted source can't run (and host all your own scripts on a separate domain which is whitelisted by CSP)