This works for me I cleared. Thanks!
spt
On 8/18/13 11:09 AM, Yoav Nir wrote:
On Aug 14, 2013, at 7:14 PM, Sean Turner <[email protected]> wrote:
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
It's interesting to note that this draft says there's a problem with
folks not checking the origins of the entire ancestor tree of names of
the framing resource - but then doesn't say that sounds like a good idea
do it. I can see the argument that might be made that this draft is just
documenting what's done now, but shouldn't we take the opportunity to do
more and recommend something along the lines of "The entire ancestor tree
of names of the framing resource SHOULD be checked to mitigate the risk
of attacks in multiple-nested scenarios" or something like that?
Hi Sean. The text has changed in version -10. There are still no RFC 2119 words there and no
recommendations to browser vendors (as we take those to be immovable objects (the implementation,
not the vendors)), but the recommendations to web developers have been changed from "should be
aware" to "should make sure". Since we are documenting a given situation, which we
hope will be changed by the CSP work, and since web developers cannot ignore the status quo (when
*is* a good time to stop targetting IE8?), does this text change satisfy you?
OLD:
For example, if a resource on origin A embeds
untrusted content from origin B, that untrusted content can embed
another resource from origin A with an X-Frame-Options: SAMEORIGIN
policy and that check would pass if the user agent only verifies the
top-level browsing context. Therefore web developers should be aware
that embedding content from other sites can leave their web pages
vulnerable to clickjacking even if the X-Frame-Options header is
used.
NEW:
a. If the browser implementation evaluates based on the origins of
the framed page and the framing page:
Suppose a web page A (from origin 1) embeds a web page B (from
origin 2) in a frame or iframe which in turn embeds web page C
(from origin 2) using the x-frame-options header in a frame. In
this case web page B needs to use X-Frame-Options as well, or
else a malicious page A could frame page B and with that
indirectly also page C. Therefore web developers should make
sure that all pages from an origin that is allowed to frame a
given resource web page C should also use X-Frame-Options or
otherwise risk exposing web page C indirectly to Clickjacking
attacks. And so forth recursively until the top-level browsing-
context (i.e. most outer frame) is reached.
b. If the browser implementation evaluates based on the origin of
the framed page and the top-level browsing-context (i.e. most
outer frame):
If a resource from origin A embeds untrusted content from origin
B, that untrusted content can embed another resource from origin
A with an X-Frame-Options: SAMEORIGIN policy and that check would
pass if the user agent only verifies the top-level browsing
context. Therefore web developers should be aware that embedding
content from other sites can leave their web pages vulnerable to
clickjacking even if the X-Frame-Options header is used.
Yoav
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
