Re: [http-state] cake and session stealing

[Adam Barth <[e-mail]>]

On Tue, Jul 27, 2010 at 11:01 AM, Thomson, Martin
<[e-mail]> wrote:
>> There's a separate cake for every origin.  In particular, there's a
>> separate cake for http://bank.com and https://bank.com.  There is no
>> way for the attacker to learn or overwrite the cake for
>> https://bank.com.  That means whatever stateful interaction the user
>> has with the server on https://bank.com is protected from the
>> attacker.
>
> When you talked about this in the meeting, you talked about the step from unsecured http to TLS secured http.  I guess I misunderstood what you were trying to achieve.

You can't hope to protect that scenario from an active network
attacker.  We're interested in protecting against a web attacker
(i.e., an attacker who controls a web site, not a MITM).  I suspect
that the notion of a web attacker is an alien concept to many folks at
the IETF, but it's a very common notion in web security.

For a rigorous definition of a web attacker, please see:

http://www.adambarth.com/papers/2010/akhawe-barth-lam-mitchell-song.pdf

>> > The only solution I see to this is to treat anything that comes in on
>> an unsecured connection as suspect.  Online shopping services do this -
>> you build a cart, but they confirm again on the secured part (sometimes
>> several times).
>>
>> If a site uses http, there's nothing we can do to protect them from a
>> MITM attacker.  We're interested in protecting https sites from MITM
>> attackers.
>
> OK, I'm still trying to come to terms with the problem that you are solving.  The problem is that you are looking for a way to have session state that is not subject to the fragility of cookies.  A server wants to be able to correlate requests from the same client because the _server_ is storing state.

Yes.

> That doesn't scale particularly well, which was Mark's comment.

That might be his opinion, but that's how virtual every web site works.

> Here's another idea: hide the state in URIs.  Rely on the fact that the URIs are only seen by the one client.  No protocol changes there.

Storing state in URLs doesn't work very well for two reasons:

1) URLs are not secret.  They leak all the time (e.g., in Referer, by
copy paste, etc.)
2) URLs have even less integrity than cookies.  Cookies can be
overwritten by a network attacker, but URLs can be overwritten by just
a web attacker.

Various folks (e.g., PHP) tried state storage in URLs and it was an
unmitigated disaster.

Adam