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

On 19/08/13 15:46, Richard Barnes wrote:
>
>
>
> On Mon, Aug 19, 2013 at 9:38 AM, Richard Barnes <rlb@ipv.sx
> <mailto:rlb@ipv.sx>> wrote:
>
>
>
>
>     On Fri, Aug 16, 2013 at 7:44 PM, Hill, Brad <bhill@paypal-inc.com
>     <mailto:bhill@paypal-inc.com>> wrote:
>
>         Additional comments inline.
>         ________________________________________
>
>
>         (D3) Shouldn't ALLOW-FROM be followed by an origin, not a URI?
>          In other
>         words, what does it mean to send "X-Frame-Options: ALLOW-FROM
>         https://example.com/this/is/a/path?query#fragment"?
>
>         [Hill, Brad] Agreed.
>
>
>     Great.
>
>      
>
>         (D3) In the ALLOW-FROM: what does "top level context" mean?
>          Do you
>         really mean the top level here, as opposed to the next one up?
>          For
>         example, suppose A loads B in an iframe, and B loads C, and
>         then C sends
>         an X-Frame-Options header with ALLOW-FROM.  Is the ALLOW-FROM
>         origin
>         compared to B or A?  In either case, you should also note the
>         attacks
>         that remain.  For example, if the answer is B, then B needs to use
>         X-Frame-Options as well, or else, A can maliciously frame A
>         within B.  Or
>         if the answer is A, then C is trusting A not to load any malicious
>         intermediate frames B.
>
>         [Hill, Brad]  This really does mean the top/final origin value
>         in a frame ancestor
>         chain walk.  Browsers have implemented X-Frame-Options to
>         check the
>         Origin context that is topmost in the window or tab.  (the
>         _top target,
>         representing the full, original browsing context, not just the
>         immediate
>         parent frame)  This could be clarified perhaps, but is not
>         incorrect.
>
>
>     OK, that's fine.  Could you please just note the risk that an
>     intermediate frame in a nested scenario could do bad things?  For
>     example, in the Security Considerations:
>     """
>     When SAMEORIGIN or ALLOW-FROM values are used, there is some
>     residual risk in nested framing scenarios.  For example, suppose
>     that A loads B in an iframe; B loads C; and C sends an
>     X-Frame-Options header with the value "ALLOW-FROM A".  The browser
>     will allow this setup, because the ALLOW-FROM origin sent by C
>     matches the top-level origin.  However, the intermediate framing
>     page B may still be able to perform clickjacking attacks against
>     A.  Thus, sites using this mechanism should keep in mind that by
>     emitting an X-Frame-Options header with value SAMEORIGIN or
>     ALLOW-FROM, they are not only granting permission to the indicated
>     origin (the same origin, or the ALLOW-FROM origin), but also to
>     any origins included as frames within that origin.
>     """
>
>
> Update: Feel free to ignore this suggestion (or steal text if you
> think it's helpful).  I think Tobias is on the right track with what
> he suggested.  That's what I get for responding to email in
> chronological order :)
>
> --Ricahrd

Dear Richard,
no problem, happens to me, too.
Synchronous and asynchronous processing. ;-)

I will keep the new revised wording in version-10 as is.

Thanks, Tobias

>
>
>  
>
>
>     Thanks,
>     --Richard
>
>
>
>
>
>
> _______________________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec