Problem/Motivation
Follow up from #3208830-27: [policy, no patch] Secondary subdomain for viewing oEmbed content is confusing and pointless
When the oEmbed system was added to the core Media module, one of the protections added against malicious JavaScript was the suggestion that site owners configure their Drupal site to be visible through a subdomain alias (basically, oembed.example.com == example.com) so that malicious JavaScript served from an oEmbed provider would have an additional hoop to jump through.
The actual oEmbed specification recommendation that the HTML within the iFrame be hosted on another domain. The intention is for the HTML within the iFrame to be entirely separate from the main site. It does not recommend using a subdomain, or that the entire site be accessible from the other domain.
We removing the warning in #2962753: Remove oEmbed security warning, given the difficulty to implement the suggestion and the lack of documentation on how to actually do it.
In the meantime we should look into more a more achievable mitigation for this issue.
Proposed resolution
It is possible to harden iframes with the sandbox attribute, which WordPress apparently does: https://core.trac.wordpress.org/ticket/44400
Next step is to experiment with adding the sandbox attribute to the oEmbed iframe, however this may break existing embeds in some cases so will require testing.
If this works, we can remove the alternate domain setting next.
Remaining tasks
TBC
User interface changes
N/A
Introduced terminology
N/A
API changes
N/A
Data model changes
N/A
Release notes snippet
N/A
Issue fork drupal-3489437
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #3
longwave#2831944-131: Implement media source plugin for remote video via oEmbed already investigated this a long time ago and found that we would have to add
sandbox="allow-same-origin allow-scripts"to get YouTube and Vimeo running, which defeats the point of using the sandbox in the first place.Comment #4
longwaveWordPress are discussing how this can be improved, and have even referenced Drupal and our iframe security settings: https://github.com/WordPress/performance/issues/1626
They seem to be running into the same issues that we have already discovered, and there is no solution yet other than the alternate domain.
Comment #5
prudloff commentedComment #7
longwaveI just read https://aifoc.us/the-browser-is-the-sandbox/#the-double-iframe-technique which mentions a technique with two nested iframes and the
sandboxandsrcdocattributes which we might be able to try, although the sandbox issues from #3 probably still apply.