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

Command icon 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

pameeela created an issue. See original summary.

longwave made their first commit to this issue’s fork.

longwave’s picture

#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.

longwave’s picture

WordPress 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.

prudloff’s picture

Issue tags: +Security improvements

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

longwave’s picture

I just read https://aifoc.us/the-browser-is-the-sandbox/#the-double-iframe-technique which mentions a technique with two nested iframes and the sandbox and srcdoc attributes which we might be able to try, although the sandbox issues from #3 probably still apply.