[policy, no patch] Secondary subdomain for viewing oEmbed content is confusing and pointless

The suggestion of an alternate domain is taken from the oEmbed spec: https://oembed.com/#section3

When a consumer displays HTML (as with video embeds), there's a vector for XSS attacks from the provider. To avoid this, it is recommended that consumers display the HTML in an iframe, hosted from another domain. This ensures that the HTML cannot access cookies from the consumer domain.

However I agree that this is a huge technical hurdle for most sites to implement.

Pointing the alternate domain at the same site makes the security benefit questionable.

From the oembed docs:
> When a consumer displays HTML (as with video embeds), there's a vector for XSS attacks from the provider

And then from the Cookie docs here

The Domain attribute specifies which hosts are allowed to receive the cookie. If unspecified, it defaults to the same host that set the cookie, excluding subdomains. If Domain is specified, then subdomains are always included. Therefore, specifying Domain is less restrictive than omitting it. However, it can be helpful when subdomains need to share information about a user.

For example, if Domain=mozilla.org is set, then cookies are available on subdomains like developer.mozilla.org.

So in summary it depends on the cookie domain - can we check if the cookie domain is set, and if it is, then we need to show a different warning.

For image styles we have a 'disable secure image generation' settings.php thing. I guess we could do the same here

$settings['media.accept_insecure_iframe_domain'] to turn this off.

I'm not sure that every browser follows the Mozilla cookie policy when the domain attribute is omitted.

Corrected description of security concern to account for Mozilla cookie policy.

For clarity, that's not the Mozilla cookie policy, its from MDN, which is a generic documentation site

See https://tools.ietf.org/html/rfc6265#section-5.1.3 for the RFC about domain name matching

Section of RFC discussing what happens if domain attribute is omitted: https://tools.ietf.org/html/rfc6265#section-4.1.2.3

How about for simple sites the ability to just turn off OEMBED? Or does that make using the media module pointless?

As 3. point in proposed resolution also avoid display of duplicate content of your Drupal site is a very critical SEO related issue, when settings this up in a right way.

I've made two edits that I would appreciate comments/feedback on from the community:

1) I propose that ASAP we should remove the existing warning. It has likely wasted 1000s of hours of site builder and developer time trying to follow the instructions, which a very low likelihood of actually providing anyone with any protection at all. It's so complex to do correctly and so lacking in documentation that I doubt even 1% of those who try do it succeed; they might even introduce security bugs by doing it incorrectly.

2) I have expanded the proposed resolution to automatically take care of as many aspects of the solution as possible to give site builders the best possible chance of getting it working.

Feedback on #19:

1) I fully agree removing the warning. I spent hours myself trying to solve that warning without luck.

2) Full fix description sounds reasonable sounds reasonable but I don't know all the nuances of cookie behavior so I can't have a strong opinion.

Discovered this issue while looking into this warning, which I have seen and ignored hundreds of times, in light of Starshot.

After reading through this and #2965979: Validate alternate domain for oEmbed iFrame I totally agree that the warning should be removed given that 1) it's extremely difficult to implement and 2) of dubious value. I understand that it's a recommendation but as it stands this feels like Drupal saying "This is a potential thing that you should maybe worry about, and we can't help you but we told you so now it's on you". In other words, very un-Drupal!

What do we need to do to get a decision on this?

Discussed with @xjm at Drupalcon Barcelona. As this policy needs review, I'm marking this needs review - so far we haven't heard any opposing voices that want to keep this feature, but I will raise this with the rest of the security team and give them chance to comment here.

I propose that ASAP we should remove the existing warning too. +1

+1 too. Please remove it

+1 for removing. Folks that know how to fix it probably don't need the reminder.

The outcome of this issue could make the following one "closed, won't fix".

I discussed this issue with @mcdruid. Some notes from the discussion:

• Injected JavaScript cannot steal session cookies if the httpOnly flag is correctly applied to those cookies which mitigates some possible attacks.
• It is possible to harden iframes with the sandbox attribute, which WordPress apparently does: https://core.trac.wordpress.org/ticket/44400 - however this may break existing embeds in some cases so will require testing.
• Credentialless iframes look like a possible future solution, but they are not yet supported in Firefox or Safari.

We agreed that this could be broken into three issues:

1. Remove the warning message, given the difficulty to implement the suggestion and the lack of documentation on how to actually do it.
2. Experiment with adding the sandbox attribute to the OEmbed iframe
3. If #2 succeeds, remove the alternate domain setting

Was reminded of this today and decided to try to move it along. Updated #2962753: Remove oEmbed security warning to be about removing the warning as the first step in #27.

I think this policy issue can be fixed?

Maybe we can convert this issue to a meta ticket holding all suggested child tickets?

Since this is a policy issue, I think it should be marked fixed once the policy is agreed. It should be referenced in the follow up issues.

Created a follow up for the sandbox experimentation.

Credited everyone who contributed to this issue (beyond just saying +1) and @lauriii for discussion in person in Singapore.

Adding credit for @mcdruid for discussing with me and raising some of the points mentioned in #27.

Adding credit for myself as per #22. Remember to credit in-person discussions, folks. :)

Changing to latest version when this was closed.