Re: HTTP without being HTTPS all the time

On Thu, Jul 19, 2012 at 08:28:58PM +0000, Poul-Henning Kamp wrote:
> In message <20120719202349.GA19857@1wt.eu>, Willy Tarreau writes:
> 
> >The risk of loading insecure
> >JS code during the HTTP phase which sets known cookies for the HTTPS
> >phase for instance exists.
> 
> Only because cookies should never be used that way.  The only safe
> cookies are signed identifying nonces, used to look up client/session
> state in a database table on the server-side.

I'm precisely speaking of these ones, as they are the only I care about.
The common principle is cookie injection :
  - attacker connects to the site and gets a session cookie
  - victim connects to the site and gets another session cookie
  - victim also loads attacker-controlled JS
  - JS replaces the victim's session cookie with attacker's cookie
  - user logs in using the attacker's cookie
  - since the attacker stil has the cookie, he can access to the client's
    account

Note that there is a solution against this : have the server rebuild a new
session cookie for every change in privilege levels and every time some
form of credentials are used. I haven't seen many sites do this unfortunately,
and even worse, some PHP-based sites accept to rebuild a new session using
a user-fed PHPSESSID cookie !

> Storing information in cookies is plain wrong no matter what you are
> trying to do security wise.

Well, it was precisely what they were designed for initially. We could
see it differently : abusing cookies to transport user preferences is
wrong because with it comes motivation to port them wherever you can,
while they should never leave the context where they were generated.

> >for moderately complex sites, better be either all clear or all secure.
> 
> Dual-mode the way I described, seems much used in "regular"
> web-commerce:  You don't need protection until you're willing to
> fork over money.

A lot of web sites switch to another site for the payment (bank, paypal
or even another host). I find this the safest method when you don't need
the site to be https. That way you keep an http-only site and don't have
to bother with the risk of mixing http/https information.

Willy

Received on Thursday, 19 July 2012 21:01:16 UTC