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

[Yoav Nir <[e-mail]>]

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