Page MenuHomePhabricator

Provide iframe sandboxing for rich-media extensions (defense in depth)
Open, MediumPublic

Description

Media-rich extensions like TimedMediaHandler, Graphs, Maps, 3D file viewer, etc pull in fairly large JavaScript libraries, give them a bunch of user-provided input, and let them do stuff with the DOM. This gives them powerful capabilities, but increases our security attack surface.

For defense in depth, it may be wise to isolate these sorts of utilities in <iframe>s using the sandbox attribute with allow-script, and/or some CSP settings to lock things down, and/or using a separate domain for the frame contents.

Since media rendering tends to happen in a defined rectangle, and the ability to export for <iframe> embedding on other sites is already desirable, it seems wise to bake the sandboxing in to the embedding export. Some possible overlap with T169026.

This can be extended further towards fancier sandboxing of user-provided scripts as in T131436, but would be beneficial even just with same-origin exclusion to keep XSS attacks from accessing the main context.

This is conceived as providing a standard interface & configuration var for setting up this kind of sandboxing, which relevant extensions can opt in to to improve their security defense-in-depth.

Basic requirements

  • PHP config vars for alternate domain if supported (otherwise must rely on sandbox attribute or CSP)
    • future applications that *require* sandboxing of user code will need to query what security guarantees are available!
  • PHP class to wrap around outputting data in an isolated iframe (cf the existing iframe output in TMH)
    • bare HTML skin; use standard RL to load relevant modules in the frame context
    • suitable interface for setting up fallback behavior when JS not available

Considerations

On non-public sites, we need to authenticate the user at the PHP level (to output an iframe) but not at the JS level (so an XSS attack can't take over your wiki account). Consider ways to do this.

Event Timeline

brion created this task.Jun 28 2017, 2:41 AM
Restricted Application added projects: Multimedia, Commons. · View Herald TranscriptJun 28 2017, 2:41 AM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Pinging the WMDE technical wishlist team, since they had at least one related wish.

Gigantic +1 to this whole thing

On non-public sites, we need to authenticate the user at the PHP level (to output an iframe) but not at the JS level (so an XSS attack can't take over your wiki account). Consider ways to do this.

At first glance, I think using sandbox attribute would accomplish this, provided that allow-same-origin is not one of the tokens provided to the attribute.

Yurik added a subscriber: Yurik.May 8 2019, 7:55 PM

Agree this would be great to have. I think this should be an API-level rather than an extension-level feature, because in many cases an extension would need to bridge the communication between inside and outside the frame. The system should allow:

  • set up a separate initial configuration blob
  • set up a separate resource loading for the iframe
  • designate some resources as only available via the iframe loading (to restrict accidental loading by the primary site)
  • establish a clear usage pattern for extensions to follow (this is more of a documentation than coding)
  • ...?
Theklan added a subscriber: Theklan.Oct 8 2019, 9:01 AM

Hello,
I have a student who is going to do her end-of-degree research adding content on advanced physics to Wikipedia and, at the same time, creating some widgets/applets to run interactivily those physical concepts, so the viewer can see how if you change some parameter you have different results. She will be working on Python.

As far as I know, we can’t embed applets at Wikimedia pages, but we can do a fixed images and link it to an external source where the applet would be stored. BUT, this is something we should start considering, as the hands-on idea is very relevant on some scientific areas.

Some days ago I discovered this: https://commons.wikimedia.org/wiki/Commons:WikiProject_WikiWidgets. So yes, inserting Widgets is possible on any given Wikimedia site. And as far as I understand this can be done via javascript. So, the question is: is it really possible to add applets or we don’t have the required technology yet and this two examples at WikiWidgets are only examples?

Tgr added a subscriber: Tgr.Oct 8 2019, 9:40 AM

Some days ago I discovered this: https://commons.wikimedia.org/wiki/Commons:WikiProject_WikiWidgets. So yes, inserting Widgets is possible on any given Wikimedia site. And as far as I understand this can be done via javascript. So, the question is: is it really possible to add applets or we don’t have the required technology yet and this two examples at WikiWidgets are only examples?

Javascript being a programming language, with full access to the page, you can add any kind of applet in it. Whether that is wise or safe or sustainable is a different matter. T190015, T71445, T39230 and T121470 describe some of the problems involved.

The problem is still the same: which is the correct way to implement this? We can have applets that make things interactive (for example, the position of Jupiter's moons) but for that it seems that we need some code review, isn't it? What would the correct jobqeueu be with this?

@Theklan - The Security-Team would probably want to at least perform a concept review (if not an entire "readiness" review) of anything like what's being discussed here. At the very least, we'd want to enumerate the risk and transfer ownership of said risk to the developers/maintainers of the code. Here's our current security review policy, which discusses both concept reviews and more formal "readiness" reviews: https://www.mediawiki.org/wiki/Security/SOP/Security_Readiness_Reviews.

It makes sense, yes. Let's assume we have some good applets to learn physics running on python somewhere. What would be the steps to follow up so we can iframe them on any given Wikipedia?

sbassett added a comment.EditedOct 8 2019, 6:19 PM

@Theklan - This is probably getting outside the original scope of this task, so it might make sense to create another task to further discuss your specific proposal. Initially, there are several concerns which come to mind here. I don't believe the technical pieces are that limiting so much as current policy and best practices along with what the future of CSP and similar protections might look like. Currently, external, third party code is not allowed to be embedded via frame, iframe, object, embed or applet tags on any production project pages as it would violate Wikimedia's privacy policy. And even if it were allowed, once Wikimedia projects begin enforcing CSP, such third party code would no longer work. So this approach is most likely a non-starter. Some possible paths forward would include the creation of a production service or MediaWiki extension which would be able to manage and render the content you are describing on Wikimedia project pages, though this can be a long path forward, especially without the sponsorship of a Wikimedia development team.

Tgr added a comment.Oct 8 2019, 10:13 PM

Presumably, if the sandbox system mentioned in this task existed, it would just be a matter of having a proxy server between the user and the third-party service.

Presumably, if the sandbox system mentioned in this task existed, it would just be a matter of having a proxy server between the user and the third-party service.

I would say, even with an iframe sandbox system, we would still want code to be served from some repo we control, instead of just proxying it. An iframe sandbox (that allows JS) stops some threats, but certainly not all of them (e.g. cryptominers, certain user tracking is probably still possible, etc).

It makes sense, yes. Let's assume we have some good applets to learn physics running on python somewhere. What would be the steps to follow up so we can iframe them on any given Wikipedia?

For starters, having the "applet" be 100% client side (other than some loading/glue code, maybe as a MW extension written in PHP) running entirely on the client side and written in javascript, would probably be more politically palatable than anything that involves server interaction (If for no other reason, less moving parts = less people you have to get on board = less redtape).

chasemp triaged this task as Medium priority.Mon, Dec 9, 5:16 PM