Re: [websec] Sean Turner's Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT)

[Sean Turner <[e-mail]>]

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 <[e-mail]> 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
>
>