Subject: [websec] X-Frame-Options and SSL

From: Devdatta Akhawe <[email-masked]>
Date: Wed, 20 Jul 2011 13:16:50 -0700

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

---

From: Adam Barth <[email-masked]>
Date: Wed, 20 Jul 2011 13:24:01 -0700

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-masked]> wrote:
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec
>
>

---

From: Devdatta Akhawe <[email-masked]>
Date: Wed, 20 Jul 2011 13:26:31 -0700

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-masked]> wrote:

> > 'secure' cookie for alice.com. In this scenario, http://www.bob.commight

---

From: Adam Barth <[email-masked]>
Date: Wed, 20 Jul 2011 13:30:49 -0700

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

---

From: Devdatta Akhawe <[email-masked]>
Date: Wed, 20 Jul 2011 13:34:13 -0700

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

---

From: "Hill, Brad" <[email-masked]>
Date: Fri, 22 Jul 2011 14:31:50 -0600

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-masked] [mailto:[email-masked]] On Behalf Of Devdatta Akhawe
Sent: Wednesday, July 20, 2011 2:34 PM
To: Adam Barth
Cc: [email-masked]
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

Adam

---

From: David Ross <[email-masked]>
Date: Fri, 22 Jul 2011 20:58:19 +0000

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-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hill, Brad
Sent: Friday, July 22, 2011 1:32 PM
To: Devdatta Akhawe; Adam Barth
Cc: [email-masked]
Subject: Re: [websec] X-Frame-Options and SSL

Brad

=dev
On 20 July 2011 13:30, Adam Barth <[email-masked]> 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-masked]> wrote:
> including jquery with an http URL, something afaik is considered not 
> safe and blocked by browsers.
>
> -devdatta
>
>> 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-masked]>
>> wrote:
>> > Hi folks
>> >
>> > Consider a site at www.alice.com that wants to only be framed by 
>> > their friends at 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
>> > 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
>> >
>> >

---

From: Devdatta Akhawe <[email-masked]>
Date: Fri, 22 Jul 2011 13:59:03 -0700

> 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

---

From: Devdatta Akhawe <[email-masked]>
Date: Fri, 22 Jul 2011 14:04:34 -0700

> weird haxoring similar to JS framebusting code but it is a pretty bad

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

---

From: "Hill, Brad" <[email-masked]>
Date: Fri, 22 Jul 2011 15:16:12 -0600

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-masked]] 
Sent: Friday, July 22, 2011 2:59 PM
To: Hill, Brad
Cc: Adam Barth; [email-masked]
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.

>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

> 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)
>
>>> > 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

---

From: Devdatta Akhawe <[email-masked]>
Date: Fri, 22 Jul 2011 14:30:45 -0700

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

---

From: "Hill, Brad" <[email-masked]>
Date: Fri, 22 Jul 2011 16:34:29 -0600

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-masked]] 
Sent: Friday, July 22, 2011 3:31 PM
To: Hill, Brad
Cc: Adam Barth; [email-masked]
Subject: Re: [websec] X-Frame-Options and SSL

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-masked]> wrote:
> From 
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-September/016
> 284.html
> ----8<--------
>> 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)
>>
>> 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
>>
>>
>>>> > 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
>>>> > 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

---

From: Devdatta Akhawe <[email-masked]>
Date: Fri, 22 Jul 2011 21:20:11 -0700

I guess I am looking at it from a more 'what-is-the-invariant'
perspective. The fact that HSTS makes everything HTTPS is a nice
simple invariant that I feel is worth maintaining.

Re. the economics argument: seems to me that you are
assuming rational behavior; that Alice.com knowingly (and fully
understanding the implications) chose to say "allow http site to frame
me."

I fear that the reason alice.com said "allow http://bob.com to frame
me" might be that alice didn't realize the implicaions.
Alice thought HSTS made her secure against active network
attacker and doesn't understand the dangers of being framed by
untrusted party.

This is similar to why people created https pages with http scripts*
in them: they didn't do this because 'the total money earned by
attackers by hijacking the script to be on the wire is less than the
cost of being on the wire'. They did it because they forgot/didn't
think of the threat.

Maintaining one simple invariant is a good thing. Having a separate
mechanism for 'make me safe against active network attacker' reminds
me of the 'secure' cookie: one had to use https as well as remember to
use 'secure' cookies to really be secure against the active network
attackers.
---

But the scenario you presented also makes sense to me. I think my
confusion was that I thought HSTS mandated browsers to block mixed
content. Rereading the draft, it seems HSTS only suggests browsers do
this (Section #10) and doesn't mandate any thing like this.

How about a similar language for HSTS enabled sites being framed by HTTP sites?

Thanks
devdatta

---

From: Tobias Gondrom <[email-masked]>
Date: Sat, 23 Jul 2011 17:28:35 +0100

Hi devdatta,

I would agree that it would be a bad idea to for https://www.alice.com 
to allow being framed by http://www.bob.com as the channel to bob would 
not be protected.

However, I am not sure that we must or even should prevent that 
behaviour inherently in the standard by shutting down any cross channel 
framing.

 From my perspective the standard should provide the tool to secure your 
application, not necessarily limit/prevent all stupid things from 
happening. (not sure whether there might be legitimate cases for such a 
scenario).

So Frame-Options gives you the chance to declare this for your web site 
not to be framed by http://www.bob.com, but if you decide to explicitly 
do so - well maybe you have a unique business case/reasons that demand 
that and you want to accept that risk still reducing the CSRF by using 
Frame-Options.

Kind regards, Tobias

On 20/07/11 21:16, Devdatta Akhawe wrote:
> Hi folks
>
> Consider a site at www.alice.com <http://www.alice.com> that wants to 
> only be framed by their friends at www.bob.com <http://www.bob.com>.
>
> 'secure' cookie for alice.com <http://alice.com>. In this scenario, 
> 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.
>
> 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 
> <http://alice.com> has enforced HSTS.
>
> What do others think ?
>
>
> thanks
> devdatta
>
>
>
>

---

From: Tobias Gondrom <[email-masked]>
Date: Sun, 24 Jul 2011 00:26:26 +0100

Hello,

so far I agree with Brad to leave the option open to be framed by a 
http-site even though you are https.  But what I also take from this, is 
that we definitely should expand on this in the Security Considerations 
Section and point out explicitly the risks of such.

So todo for the next version will be to add an Security Considerations 
section explaining why you SHOULD NOT (RFC2119) do it and what potential 
security risks will arise if you do it.

Thanks a lot for your reviews and your feedback pointing that out.

Tobias

On 23/07/11 05:20, Devdatta Akhawe wrote:
> On 22 July 2011 15:34, Hill, Brad<[email-masked]>  wrote:
>> On 22 July 2011 14:16, Hill, Brad<[email-masked]>  wrote:
>>>> On 20 July 2011 13:30, Adam Barth<[email-masked]>  wrote:
>>>> On Wed, Jul 20, 2011 at 1:26 PM, Devdatta Akhawe<[email-masked]>  wrote:
>>>>> On 20 July 2011 13:24, Adam Barth<[email-masked]>  wrote: