On 22 July 2011 13:59, Devdatta Akhawe <[email protected]> wrote: >> 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.
Err .. my bad. Alice can just say "https://"; in its allow-from Directive. Ignore the first part of the message and just see the note about how it is similar to mixed-content -devdatta > > 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
