Re:

> I investigated binding cookies to the client IP, but that would require encrypting the cookie along with the client IP stored within it.  That would still leave users behind a proxy or NAT vulnerable, and I have reports that client IPs may change.  The IP changing feature occurs for a small but significant (less than 10%?) of my site's users.

Well, you don't actually need to encrypt, you could just have a keyed hash of the IP address (where the key is known only to the server).  But that doesn't address the IP changing features. 

If you want to emulate the TLS client cert approach, you could use localStorage to store a private key, and use JS crypto [1] to replace document.cookie with a signed version.  It's a little clunky, but it might be made to work.  (Obviously, would be better with web crypto [2])

[1] for example: http://www.ohdave.com/rsa/
[2] http://www.w3.org/community/webcryptoapi/




>  
> 
> From: Richard L. Barnes <rbarnes@bbn.com>
> To: Enduro USA Tour <endurousatour@yahoo.com> 
> Cc: "public-web-security@w3.org" <public-web-security@w3.org> 
> Sent: Monday, March 12, 2012 10:25 AM
> Subject: Re: 
> 
> There's some related work proposed in the IETF TLS working group.  The idea there is to bind cookies to TLS client certificates, so as long as the private key corresponding to the cert is only on one machine, the cookie can only be used on one machine.
> <http://tools.ietf.org/html/draft-balfanz-tls-obc-01>
> 
> Of course, you could also just associate cookies with a client IP addresses on the server side...
> 
> 
> 
> On Mar 11, 2012, at 11:53 AM, Enduro USA Tour wrote:
> 
> >  
> > I'm an independent security researcher and am interested in addressing
> > Related Domain Cookie Attacks.  See these links for more info on the
> > problem:
> > 
> > http://security.stackexchange.com/q/12412/396  and
> > http://stackoverflow.com/q/9636857/328397
> > 
> > I would like to pitch a few approaches on addressing this vulnerability,
> > but before I do that, is anyone aware of a solution that binds a cookie to
> > a host, limiting the ability of the attacker to transfer or replay it on a
> > different host?  That is essentially the vulnerability that is described in
> > the links above.
> > 
> > Before I pitch my solution, I'd like to see if you agree that the issue is
> > relevant to this group, and of importance.
> > 
> > Thanks for your time!
> > 
> > Chris Lamont Mankowski
> > 
> > 
> > 
> 
> 
>

Received on Monday, 12 March 2012 15:46:45 UTC