New issue
Advanced search Search tips

Issue 805964 link

Starred by 2 users

Issue metadata

Status: Duplicate
Merged: issue 129139
Owner: ----
Closed: Jan 2018
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: ----
Type: Bug-Security



Sign in to add a comment

Security: Chrome ignores the X-Frame-Options: ALLOW-FROM header

Reported by tony.r...@gmail.com, Jan 25 2018

Issue description

VULNERABILITY DETAILS
Chrome ignores the X-Frame-Options: ALLOW-FROM header

I have a form on one server that correctly sets the X-Frame-Options header to "ALLOW-FROM https://www.radiodetection.com" When viewing on Chrome, the form displays when I iFrame it into a page on "https://radiodetection.pleasetest.co.uk" which I believe it should not.  On Edge, it displays a message that the publisher won't allow it to be displayed in an iFrame which seems reasonable behaviour.

VERSION
63.0.3239.132 (Official Build) (32-bit) (cohort: Stable)
Revision	2e6edcfee630baa3775f37cb11796b1603a64360-refs/branch-heads/3239@{#709}
OS: Windows 10 Enterprise

REPRODUCTION CASE

The form is : https://secure.radiodetection.com/warranty/WarrantyRegistration.aspx

From the Developer Tools:

General Headers are:
Request URL:https://secure.radiodetection.com/warranty/WarrantyRegistration.aspx
Request Method:GET
Status Code:200 OK
Remote Address:146.177.11.226:443
Referrer Policy:no-referrer-when-downgrade

The response headers are: 
HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Vary: Accept-Encoding
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
X-Frame-Options: ALLOW-FROM https://www.radiodetection.com
Date: Thu, 25 Jan 2018 16:59:25 GMT
Content-Length: 6037

The Request headers are:
GET /warranty/WarrantyRegistration.aspx HTTP/1.1
Host: secure.radiodetection.com
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Referer: https://radiodetection.pleasetest.co.uk/en/extended-warranty-registration
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9,en-GB;q=0.8
Cookie: _hp2_id.2757902115=%7B%22userId%22%3Anull%2C%22pageviewId%22%3A%222398969827088527%22%2C%22sessionId%22%3A%227210171723002646%22%2C%22identity%22%3A%22d34463f052d2c4783c4352d2aa4d002bd818fbc6%22%2C%22trackerVersion%22%3A%223.0%22%7D; _ga=GA1.2.1364785045.1502266040; _gid=GA1.2.237774478.1516647483

 
Mergedinto: 129139
Status: Duplicate (was: Unconfirmed)
This directive was never implemented in Chrome. You might consider using Content Security Policy's Frame-Ancestors directive instead.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors

Comment 2 by tony.r...@gmail.com, Jan 25 2018

Thanks for the speedy and helpful reply.  

The use of X-Frame-Options is recommended pretty widely across the web (for example on OWASP).  The knowledge that the most popular browser does not support it is not widely reported.

I did spot the CSP Frame-Ancestor stuff, and we'll use that instead - or perhaps we need both.

I think it's really concerning that this technique is being recommended, but for most situations has no effect.

Thanks
Tony
For clarity, it should be noted that Chrome supports X-Frame-Options tokens *other than* the ALLOW-FROM directive. 
Project Member

Comment 4 by sheriffbot@chromium.org, May 4 2018

Labels: -Restrict-View-SecurityTeam allpublic
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Sign in to add a comment