The draft RFC currently states: > Any data beyond the domain address (i.e. any data after the "/" > separator) is to be ignored and to verify a referring page is of the > same origin as the content or that the referring page is listed in > the ALLOW-FROM list of URI, the algorithm to compare origins from > [ORIGIN] should be used.
To address the concern we could add a sentence like: --- Implementations should block HTTPS content from utilizing ALLOW-FROM references to non-HTTPS URIs. --- I'd vote to add it, just because it's easy, and "should" implies a recommendation rather than a requirement. David Ross [email protected] -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Hill, Brad Sent: Friday, July 22, 2011 1:32 PM To: Devdatta Akhawe; Adam Barth Cc: [email protected] Subject: Re: [websec] X-Frame-Options and SSL Devdatta is correct that allowing an insecure page to frame a secure one, even with permission, presents a clickjacking risk in the presence of an active network attacker. Not to gratuitously muddy the waters, but I'm of two minds about the proposed measure: 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 _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
