> I guess I'm leaning towards "this is a weakness, but we shouldn't do anything > about it."
Say alice.com does care about this. My problem with the above position is alice.com can do nothing about this weakness. There is no flag it can send to say "hey don't allow insecure things to frame me: I am really worried about the active network attacker." It can do some weird haxoring similar to JS framebusting code but it is a pretty bad thing. To me, this is similar to the original motivations for XFO. >From >http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-September/016284.html ----8<-------- "For a couple of months now, along with a number of my colleagues at Google, we were investigating a security problem that we feel is very difficult or impossible to avoid on application side, and might be best addressed on HTML or HTTP level in contemporary browsers." ---->8---------- My view is that this weakness is similar to mixed content. Modern browsers (e.g., IE9) block mixed content by default while still allowing a click to enable it. I feel in the same style this should be blocked, while still allowing the user to click through. And in the same spirit, if the secure page being framed is HSTS enabled then there shouldn't be an option to the user to click through. =Devdatta > > 1) Don't add the invariant, because moving the threat from remote to active > is still a significant reduction in attack surface while maintaining > compatibility with existing usages. If we break that, the alternative is > probably to have no protections. > > 2) Add the invariant because existing uses of this pattern are already > broken: the user can't readily verify the origin of or that the framed > content is, in fact, secure. This is only a Spoofing risk, however, and so > is less severe than the direct Elevation of Privilege allowed by > clickjacking. (spoofing a "like" or "pay" button doesn't get an attacker > much) > > I guess I'm leaning towards "this is a weakness, but we shouldn't do anything > about it." > > Brad > > From: [email protected] [mailto:[email protected]] On Behalf Of > Devdatta Akhawe > Sent: Wednesday, July 20, 2011 2:34 PM > To: Adam Barth > Cc: [email protected] > Subject: Re: [websec] X-Frame-Options and SSL > > In case of http bob including https jquery, the HTTPS Jquery will run with > the privileges of http bob. > > In the other case, https alice frame will run with the privileges of https > alice > > > =dev > On 20 July 2011 13:30, Adam Barth <[email protected]> wrote: > Why is that? We're talking about HTTP Bob including HTTPS Alice, just > like we're talking about an HTTP page including HTTPS jQuery. > > Adam > > > On Wed, Jul 20, 2011 at 1:26 PM, Devdatta Akhawe <[email protected]> wrote: >> The invariant I am talking about is more comparable to an https page >> including jquery with an http URL, something afaik is considered not safe >> and blocked by browsers. >> >> -devdatta >> >> On 20 July 2011 13:24, Adam Barth <[email protected]> wrote: >>> >>> I'm not sure that invariant makes sense. As another example, it seems >>> entirely reasonable for an HTTP page to include a copy of jQuery from >>> an HTTPS URL. >>> >>> Adam >>> >>> >>> On Wed, Jul 20, 2011 at 1:16 PM, Devdatta Akhawe <[email protected]> >>> wrote: >>> > Hi folks >>> > >>> > Consider a site at www.alice.com that wants to only be framed by their >>> > friends at www.bob.com. >>> > >>> > Say, a request to https://www.alice.com might respond with a >>> > X-Frame-Options: allow-from http://www.bob.com >>> > >>> > Clearly, the https://www.alice.com has the privileges to act with the >>> > 'secure' cookie for alice.com. In this scenario, http://www.bob.com >>> > might >>> > actually be MITM'ed by Mallory and contain malicious code. In this >>> > scenario, >>> > does it make sense to allow http://www.bob.example to frame >>> > https://www.alice.example? I think this is wrong behavior: a more higher >>> > level invariant that should be maintained (at least in the newer specs >>> > :) is >>> > that only HTTPS content has access to secure cookie privileges. >>> > >>> > Thus, I think the right thing to do is : >>> > Enforce https for all the origins in the list returned in allow-from by >>> > https://www.alice.com. Even if https://www.alice.com responds with >>> > http://www.bob.com in its X-Frame-Options, the browser should only allow >>> > https://www.bob.com to frame https://www.alice.com >>> > >>> > >>> > I think this is even more compelling in case alice.com has enforced >>> > HSTS. >>> > >>> > What do others think ? >>> > >>> > >>> > thanks >>> > devdatta >>> > >>> > >>> > >>> > _______________________________________________ >>> > websec mailing list >>> > [email protected] >>> > https://www.ietf.org/mailman/listinfo/websec >>> > >>> > >> >> > > _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
