Page MenuHomePhabricator

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

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)
  • ...?