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.