WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
Bug 94836
Support for X-Frame-Options: Allow-From [uri]
https://bugs.webkit.org/show_bug.cgi?id=94836
Summary
Support for X-Frame-Options: Allow-From [uri]
Phil Ames
Reported
2012-08-23 12:55:10 PDT
Related to
https://bugs.webkit.org/show_bug.cgi?id=23907
(hence the initial CC's) Attached is a patch which enables support for “Allow-From [uri]” notation in the X-Frame-Options header. I compared the behavior of patched Chrome with IE9 with the below values (syntax:IE permitted/patched Chrome permitted/header-value) which was sent by a cross-origin site (the top origin was
http://www.intra.net/
) Probably the most substantial difference is that IE doesn’t seem to regard the port number. A similar patch for Firefox which I will be submitting soon (to
https://bugzilla.mozilla.org/show_bug.cgi?id=690168
) produces the same behavior as this patch to Chrome, though. N/N/X-Frame-Options: Allow-From N/N/X-Frame-Options: Allow-From xyz N/N/X-Frame-Options: Allow-From www.intra.net Y/Y/X-Frame-Options: Allow-From
http://www.intra.net
Y/Y/X-Frame-Options: Allow-From
http://www.intra.net/
Y/Y/X-Frame-Options: Allow-From
http://www.intra.net:80/
Y/N/X-Frame-Options: Allow-From
http://www.intra.net:81/
Y/N/X-Frame-Options: Allow-From
http://www.intra.net:443/
Y/Y/X-Frame-Options: Allow-From
http://www.intra.net/foo/bar/
Please also note that although I modelled the LayoutTests after the ones that I found in the existing tree, I was not actually able to get them to run on my development environment, so they may require some tweaking (sorry, if anyone is at Google and wants to spend a few minutes helping me troubleshoot / get it working, I’d be happy to test and send an additional diff). The results in the table above are solely from ‘empirical’ testing/observation.
Attachments
Patch
(6.56 KB, patch)
2012-08-23 12:55 PDT
,
Phil Ames
no flags
Details
Formatted Diff
Diff
Updated patch.
(5.91 KB, patch)
2012-08-28 19:12 PDT
,
Phil Ames
abarth
: review-
Details
Formatted Diff
Diff
X-F-O Allow From implementation
(10.65 KB, patch)
2013-04-12 09:20 PDT
,
Phil Ames
no flags
Details
Formatted Diff
Diff
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
Phil Ames
Comment 1
2012-08-23 12:55:39 PDT
Created
attachment 160219
[details]
Patch
Phil Ames
Comment 2
2012-08-23 12:58:36 PDT
[trying to cc myself]
Adam Barth
Comment 3
2012-08-23 13:00:20 PDT
Note: We're still discussing this feature in the IETF websec working group. Generally, our position has been that we shouldn't be adding new features to X-Frame-Options. Instead, we should create a CSP directive that satisfies these use cases.
Phil Ames
Comment 4
2012-08-28 19:12:11 PDT
Created
attachment 161116
[details]
Updated patch. FYI: I managed to get the layout tests passing, and also addressed that this would accept something like "Allow-Fromhttp://foo.com" instead of "Allow-From
http://foo.com
".
Adam Barth
Comment 5
2012-08-28 19:23:38 PDT
@Phil: I appreciate your enthusiasm, but it's unlikely that we'll accept this patch until the standards issues are resolved.
Phil Ames
Comment 6
2012-08-28 19:24:30 PDT
Understood, I just figured it made sense to have something up-to-date and attached here rather than something broken.
Phil Ames
Comment 7
2013-04-12 09:20:05 PDT
Created
attachment 197858
[details]
X-F-O Allow From implementation I noticed this code had been refactored, so I've updated the patch.
Brady Eidson
Comment 8
2013-04-16 17:45:32 PDT
In radar as <
rdar://problem/13658368
> I'll try to take a look at this patch soon.
Adam Barth
Comment 9
2013-04-16 18:25:23 PDT
(In reply to
comment #8
)
> In radar as <
rdar://problem/13658368
> > > I'll try to take a look at this patch soon.
You should be aware that this feature is controversial in the W3C WebAppSec working group. Before implementing it, you might want to confer with the working group.
Brady Eidson
Comment 10
2013-04-16 21:42:36 PDT
(In reply to
comment #9
)
> (In reply to
comment #8
) > > In radar as <
rdar://problem/13658368
> > > > > I'll try to take a look at this patch soon. > > You should be aware that this feature is controversial in the W3C WebAppSec working group. Before implementing it, you might want to confer with the working group.
Interesting. We were looking at it because it's been in the IETF draft for some time (
http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-01
) and has utility we're interested in. I'm failing at finding relevant threads in the webappsec archives that demonstrate this controversy. Have any pointers?
Adam Barth
Comment 11
2013-04-16 21:58:26 PDT
> We were looking at it because it's been in the IETF draft for some time (
http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-01
) and has utility we're interested in.
The IETF websec working group has not addressed my WGLC feedback on this aspect of draft-ietf-websec-x-frame-options:
http://www.ietf.org/mail-archive/web/websec/current/msg01459.html
> I'm failing at finding relevant threads in the webappsec archives that demonstrate this controversy. Have any pointers?
I couldn't find a good email thread in quick search. The basic issue is that allow-from is basically the same thing as a source-expression from CSP but uses an incompatible syntax. The current agreement in both the IETF websec working group and the W3C WebAppSec working group is to not add any new features to X-Frame-Options (including allow-from) and instead make frame-options into a CSP directive. The final point of controversy is whether to let the web site specify multiple values for the frame-options directive (i.e., whether to allow a source-list like other CSP directives or whether to restrict frame-options to a single source-expression). I'd recommend not implementing allow-from in X-Frame-Options until these issues are resolved. I'd expect the likely outcome to be a frame-options CSP directive that either takes a source-list or a source-expression. The W3C WebAppSec working group has a face-to-face meeting on April 25-26 where I'd expect these issues to be hammered out. If you're interested in these topics, I'd encourage you to attend.
Brady Eidson
Comment 12
2013-04-16 22:21:04 PDT
I'll try to be on IRC.
Adam Hooper
Comment 13
2014-06-25 06:44:17 PDT
Has the standards process stalled here? In October 2013, IETF published
http://tools.ietf.org/html/rfc7034
(informative) related to X-Frame-Options. Meanwhile, the CSP working draft shows nothing but a TODO:
https://dvcs.w3.org/hg/content-security-policy/raw-file/5b353a8ac072/csp-specification.dev.html#frame-options--experimental
Allow-From solves a real problem. Because WebKit ignores it, websites can be forced to abandon X-Frame-Options altogether. Given there's an RFC on the topic, could we please have Allow-From?
Alexey Proskuryakov
Comment 14
2014-12-18 09:56:59 PST
CSP 1.1 now supports this use case, directive name is frame-ancestors. It's not implemented in WebKit yet.
Mike Hemesath
Comment 15
2016-02-12 07:36:56 PST
Is there an issue logged for implementing frame-ancestors in webkit?
Brent Fulgham
Comment 16
2016-05-27 12:19:47 PDT
(In reply to
comment #15
)
> Is there an issue logged for implementing frame-ancestors in webkit?
Yes. This work was done under
Bug 154345
, and is now complete.
Brent Fulgham
Comment 17
2016-05-27 12:20:29 PDT
Since the new CSP feature has been implemented, this issue is resolved.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug