Context:

Clickjacking-prevention was added to Drupal Core (7.50 & 8) in #2514136: Add default clickjacking defense to core
X-Frame-Options: SameOrigin

Problem / Motivation:

X-Frame-Options allows only one ALLOW-FROM url to be set, which is not even supported in all browsers (compatibility: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options). Chrome and Safari finally decided to NOT support it: https://code.google.com/p/chromium/issues/detail?id=129139
(Further details on deprecation: http://stackoverflow.com/a/25617678)

X-Frame-Options leads to big problems here by default. For example the Google image search does NO MORE show a website preview when an image is clicked due to X-Frame-Options policy.
Example for Drupal.org: http://images.google.de/imgres?imgurl=https%3A%2F%2Fwww.drupal.org%2Ffil...

But because Google uses different TLDs for different countries, they can not be cleanly white-listed (see above: only 1 url allowed).

I think many Drupal 7/8 users have not yet found out, that their website is not being displayed in Google image search properly. That should be reason enough to implement a better solution in core.

Proposed solution:

Content-Security-Policy: frame-ancestors 'self' example.com *.example.net ; seems to be the follow-up of X-Frame-Options. See https://developer.mozilla.org/de/docs/Web/Security/CSP
It allows to define whitelisting patterns and would solve the problem stated out above.
If it has no security drawbacks, it should replace x-frame-options in core completely I think.
https://www.owasp.org/index.php/Content_Security_Policy_Cheat_Sheet#Prev...

What has to be done:

Find out if there are security implications when using Content-Security-Policy instead of X-Frame-Options
Define how to set the whitelist by variable (string or array?)
Perhaps make x_frame_options variable values backwards compatible?
Backport to D7

CommentFileSizeAuthor
#3 drupal.org x-frame-options google images.JPG77.82 KBAnybody
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Anybody created an issue. See original summary.

Anybody’s picture

Anybody
Primary language German
Location Porta Westfalica
CreditAttribution: Anybody at DROWL.de commented
Issue summary: View changes
Anybody’s picture

Anybody
Primary language German
Location Porta Westfalica
CreditAttribution: Anybody at DROWL.de commented
FileSize
drupal.org x-frame-options google images.JPG77.82 KB

I added an example that even Drupal.org is affected by this problem. Google image search results do not show a preview of the page ;)
Search for "drupal.org" in google image search and click the Drupal logo for example:
drupal.org x-frame-options google images

Anybody’s picture

Anybody
Primary language German
Location Porta Westfalica
CreditAttribution: Anybody at DROWL.de commented

In Drupal 7 you can deactivate X-Frame-Options in settings.php by adding:

Turn off the X-Frame-Options header entirely, to restore the previous
behavior of allowing the site to be embedded in a frame on another site.
$conf['x_frame_options'] = '';
David_Rothstein’s picture

David_Rothstein CreditAttribution: David_Rothstein as a volunteer commented

For example the Google image search does NO MORE show a website preview when an image is clicked due to X-Frame-Options policy.
...
I added an example that even Drupal.org is affected by this problem.

This is odd - the blank screen that shows up on https://www.google.de seems to be limited to that Google language site only (or at least, I couldn't reproduce it on others). It tries to show you the website preview iframe only, but for some reason never tries to show you the image itself.

Other sites have different behavior when clicking on an image search result, all of which work acceptably:

https://www.google.com (shows the image inline in the search results page)
https://www.google.es (shows the image inline in the search results page)
https://www.google.hu (shows the image inline in the search results page)
https://www.google.fr (shows the image overlaid on a website preview/iframe - so for drupal.org the iframe doesn't work here either, but that just means the image is overlaid on a gray background instead which is acceptable)

So it's almost like www.google.de is trying to do what www.google.fr does, but forgetting to actually overlay the image.... This seems like a bug with www.google.de that you should report to Google - nothing that Drupal is doing wrong here.

Content-Security-Policy "frame-ancestors" looks interesting, but doesn't seem to have enough browser support yet to be a replacement for X-Frame-Options (no Internet Explorer or Edge support): https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Securi.... Also, I don't see anything that says X-Frame-Options is deprecated yet, just that it will be deprecated someday in the future.

Anybody’s picture

Anybody
Primary language German
Location Porta Westfalica
CreditAttribution: Anybody at DROWL.de commented

Hi David,

thanks a lot for your reply and stating out Googles misbehaviour. I'll try to report the issue to Google (hoping I'll find a place for that ;)).

The huge problem I see with X-Frame-Options is that it only allows exactly one domain to be whitelisted. We even had the problem that SameOrigin does not work (no frames from the SAME page) when we whitelisted images.google.de. That's so scary and as it seems it's by design.

So images.google.de is surely the most important place I know so far, where the problem appears, but I think there will be many other usecases where you will need more than exactly one domain to be whitelisted.

Content-Security-Policy has a much better concept but you're right, it's not supported by older browsers.
BUT we could discuss if we should not be more flexible about that because X-Frame-Options is no real big security because the client browser has to support it and the server has no control about that.

However we should at least ensure that Content-Security-Policy is used as replacement as early as possible, because it's a lot smarter.

Drupal is not the only system dealing with this issue:

David_Rothstein’s picture

David_Rothstein CreditAttribution: David_Rothstein as a volunteer commented

The huge problem I see with X-Frame-Options is that it only allows exactly one domain to be whitelisted.

True, but if you use https://www.drupal.org/project/seckit to set the Allow-From option it has a workaround which allows you to whitelist as many domains as you want (basically it dynamically sets Allow-From based on the current page request; see http://cgit.drupalcode.org/seckit/tree/seckit.module?h=7.x-1.9#n121).

I guess it is still true that Allow-From doesn't work on all browsers though.

Anybody’s picture

Anybody
Primary language German
Location Porta Westfalica
CreditAttribution: Anybody at DROWL.de commented

Thank you very much for the module link. That's at least a workaround :)

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

gapple’s picture

gapple
he/they
Primary language English
CreditAttribution: gapple as a volunteer commented

Is this issue covered by #2513356: Add a default CSP and clickjacking defence and minimal API for CSP to core enough that it can be closed as a duplicate?

gapple’s picture

gapple
he/they
Primary language English
CreditAttribution: gapple as a volunteer commented
Related issues: +#2513356: Add a default CSP and clickjacking defence and minimal API for CSP to core

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

gapple’s picture

gapple
he/they
Primary language English
CreditAttribution: gapple as a volunteer commented
Issue tags: +Content Security Policy

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

geek-merlin’s picture

geek-merlin
they/omg
Primary language German
Location Freiburg, Germany
CreditAttribution: geek-merlin at MachbarMacher commented

Browser compatibility has gotten a lot better...

gapple’s picture

gapple
he/they
Primary language English
CreditAttribution: gapple as a volunteer commented
Status: Active » Closed (duplicate)

Closing this issue in favour of #2513356: Add a default CSP and clickjacking defence and minimal API for CSP to core.

Retaining X-Frame-Options provides a security improvement for browsers which do support it and sites can override it, disable it, or use SecKit's dynamic ALLOW-FROM based on referrer as needed.

gapple’s picture

gapple
he/they
Primary language English
CreditAttribution: gapple as a volunteer commented

I guess a question to remain open is when should Drupal core stop setting a default X-Frame-Options header.

IE 11 doesn't (and won't) support Content Security Policy, so it will be the only browser that doesn't have an alternative solution and loses protection if X-Frame-Options is removed.