Hacker News Reader

Comment by donaldstufft | Hacker News Reader

An unrelated HTTP session cannot set a cookie for another domain (unless it's a subdomain in which you have the more serious issue of session theft or session fixation). The solution to both of these problems is HSTS with the includeSubDomains option.

View on HN

1) simulate request to http(NOT SECURE)://site.com 2) simulate response with Set-Cookie: csrf_token=123123;

> unless it's a subdomain in which you have the more serious issue of session theft or session fixation

elaborate plz? From what I know, subdomain can only do same attack (cookie tossing). Are you talking about phishing?

Except we can set the cookie because we're already doing that to HTTPS requests via cookie-forcing.

I've just woken up and I haven't tested it, but off the cuff I believe HSTS will prevent the browser from trusting a plaintext HTTP response at all. So you cannot force a cookie if I understand the blog post correctly. You'd have to create a cookie inside of a verifiable HTTPS connection, which if you can do you've already executed a much worse attack.

> but off the cuff I believe HSTS will prevent the browser from trusting a plaintext HTTP response at all

Cookies are broken (i write about it on my blog like, daily). The essential idea of Forcing is injecting cookies into HTTPS space from HTTP.

@homakov, so you can get a browser to trust a cookie from a HTTP response under a domain protected by HSTS?

Doesn't HSTS just mean that the browser will just always make HTTPS responses?

I think this is what it hinges on:

http://scarybeastsecurity.blogspot.com.es/2008/11/cookie-for...

Is that possible under HSTS?

Reply on news.ycombinator.com