Problem/Motivation
This issue is spun off from the pile-on happening in
✨
[PP-1] Validate alternate domain for oEmbed iFrame
Postponed
.
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. We felt strongly enough about this measure that, if oEmbed content is not served in a subdomain, we display a warning on the status report page.
However, this is tricky to set up -- it's poorly documented and the warning drives site builders crazy (as evidenced by discussion in
✨
[PP-1] Validate alternate domain for oEmbed iFrame
Postponed
) until they get it set up properly. And even when they do, it's not clear that there is actually a security improvement here.
- If a subdomain is used, browsers consider it to be part of the main site, so it can share cookies with the main domain.
- If a completely different domain is used instead of a subdomain, users can go directly to the second domain, which, because it is the same Drupal site, is configured to use itself as the iFrame domain.
The oEmbed specification recommends 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.
Steps to reproduce
Install the Standard profile and the Media module, then visit the status report page.
Proposed resolution
Quick fix
Given that the full fix is complex and will take some time to develop, I [AdamPS] propose that ASAP we could remove the existing warning. It has likely wasted 1000s of hours of site builder and developer time trying to follow the instructions, which a low likelihood of actually providing anyone with any protection at all. It's so complex to do correctly and lacking in accurate full documentation that I doubt even 1% of those who try do it succeed; they might even introduce security bugs by doing it incorrectly.
Full fix
- In the iFrame domain only serve pages that should be used there. Block these pages in the main domain. If there is not an iFrame domain, use a data URL and sandbox attribute to minimize the possibility of cookies leaking into the iFrame.
- Automatically set same-origin policy so that the embedding actually works
- Don't allow the iFrame domain to be a sub-domain of the main domain OR find a way to set a cookie policy so that the sub-domain cannot share cookies with the main domain
- Treat the iFrame domain as trusted specifically for the pages that it should serve without needing to set it in the list of trusted hosts
- Provide a way to disable the warning given that the site is still reasonably secure without the extra domain and not everyone will want to purchase an extra domain.
- Provide detailed documentation for site builders.
Remaining tasks
TBD
User interface changes
TBD
API changes
TBD
Data model changes
TBD
Release notes snippet