No, the clickjacking risk against an individual resource can still be managed
independently of HSTS.
It's not just about the attacker, it's about the asset. HSTS can be used to
protect high value assets like credentials and sessions without implying that
every inbound click is high value or not subject to other controls.
Let's take a purely hypothetical scenario where alice.com wants to put a button
in a frame on example.com. Let's also say that every hijacked click to
alice.com against a U.S. user of example.com can generate a revenue of $0.02
for an attacker. Alice.com deploys HSTS but example.com doesn't deploy https.
Alice.com believes it can generate revenues of $500/day from example.com.
Example.com believes it can generate revenue of $500/day from the partnership,
but can't be convinced to move to https because that would cost $1000/day -
more than the total value of the partnership.
If we let "https://alice.com/exampleDotComButton"; set XFO to "ALLOW
http://example.com";, there is the possibility that an attacker can set up in a U.S. coffee
shop as an active MITM. Such an attacker might make $0.50 a day. This is probably not worth the
cost of mounting the attack, and alice.com might notice the attack and add controls based on the
originating IP or address block before any significant money flows to the attacker. Because of
this, alice.com's expected loss with XFO to the insecure site is maybe only $0.06/day and it is
willing to accept this risk.
If alice.com doesn't deploy any XFO headers, attackers can operate out of
countries with a low cost of living, ensnare many more users, and generate
fraud revenues of $100/day.
If we change XFO so that sites that deploy HSTS require https-only framing,
alice.com is left with only bad choices: bear the risk of clickjacking, turn
off HSTS, or don't partner and forgo the revenue from example.com.
-Brad
-----Original Message-----
From: Devdatta Akhawe [mailto:[email protected]]
Sent: Friday, July 22, 2011 3:31 PM
To: Hill, Brad
Cc: Adam Barth; [email protected]
Subject: Re: [websec] X-Frame-Options and SSL
Yes, but IE9 (e.g.) blocks mixed stylesheets, frames, objects too.
Anyways, the point of the thread was to bring up discussion on this possible weakness. I
(really) don't care much on what should be done in the default case. Whatever decision is
taken by the WG, I think a note should be added in the "Security
Considerations" section to that effect.
What I do feel strongly about is the case where the secure site being framed is HSTS
enabled. In such a scenario, the browser should block the insecure frame from framing the
secure site. Clearly, in the HSTS case, the site has told the browser "I really care
about the active network attacker scenario" and as such the browser should be
proactive against the active network attacker. Do you agree?
-devdatta
On 22 July 2011 14:16, Hill, Brad<[email protected]> wrote:
In this case alice.com can only include http://bob.com. I'm not saying we
should force inclusion of http://bob.com, I'm just saying we shouldn't ban it,
because it's a lot better than nothing.
It is alike in concept to mixed content, but on a greatly reduced attack surface: Routing a click
to a location on a page vs. (in the case of an mixed script src) full control of the secure DOM.
For a business deploying XFO, that difference is pretty important. Alice.com may want to be able
to have a "like" or "pay" button from a secure source framed by the insecure
bob.com because the risk/fraud rates from only active attackers may be acceptable or amenable to
other compensating controls, where those from generalized remote clickjacking may not.
Brad
-----Original Message-----
From: Devdatta Akhawe [mailto:[email protected]]
Sent: Friday, July 22, 2011 2:59 PM
To: Hill, Brad
Cc: Adam Barth; [email protected]
Subject: Re: [websec] X-Frame-Options and SSL
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/016
284.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
