3

In this question, I want to identify browsers, servers, or implementations that are immune from related domain cookie attacks (e.g. a.example.com vs b.example.com).

Lacking any tangible solution, could this mitigated by software that tracks and verifies each cookie's "type" and persists that.

Update:

The answer is that no current browser or technology is protected from these attacks. Learn more here: https://stackoverflow.com/q/9636857/328397

Community
  • 1
makerofthings7
  • 50,090
  • 54
  • 250
  • 536
  • 1
    A quick comment: I don't think "cookie jar overflow" is the term you want. That refers to one particular attack method (flooding the browser with so many cookies that it starts to evict other cookies). I suspect you are asking more generally about all attacks that could allow a malicious server in a related but not identical domain to overwrite, modify, or delete cookies. – D.W. Mar 06 '12 at 21:04
  • @D.W. I renamed it to "same domain cookie attacks"... how does that sound? – makerofthings7 Mar 06 '12 at 22:15
  • 2
    Better, but it's not the same domain (if it were the exact same domain, there would be no defense, thanks to the same-origin policy), but related domains that share a common suffix: e.g., `a.example.com` vs `b.example.com`. – D.W. Mar 07 '12 at 00:23
  • 1
    @D.W. Ahh, `related domain cookie attacks` makes a lot more sense then what I wrote there before! – makerofthings7 Mar 07 '12 at 01:14
  • Do we need a `vulnerable-by-design` tag? – curiousguy Jun 30 '12 at 13:56

1 Answers1

4

I want to identify browsers, servers, or implementations that are immune from related domain cookie attacks (e.g. a.example.com vs b.example.com).

That is simple: there are none. It's a basic part of the design of cookies that a.example.com gets to write cookies scoped to example.com, that will be picked up by b.example.com.

There are browser differences in what cookies ‘wins’ when the same name is defined at multiple levels, and there is a difference in IE vs the other browsers in that IE will scope a cookie set at a.example.com to *.a.example.com if it has no domain, whereas other browsers scope it to only the exact domain.

Lacking any tangible solution, could this mitigated by software that tracks and verifies each cookie's "type" and persists that.

Not directly. There is no way to read the domain/path/etc options from a cookie.

All you can do is attempt to guess at what level the cookie was set, and try to verify that by deleting the cookie at that level (by settings expires in the past). If the cookie disappears, you guessed right; if it's still there, try a different domain/path combination.

bobince
  • 12,494
  • 1
  • 26
  • 42
  • "_attempt to guess at what level the cookie was set,_" what if I guess the cookie is at some level (example.com), and I add a cookie at another level (foo.example.com), would that be a way to verify my guess? – curiousguy Jun 27 '12 at 23:30
  • @curiousguy: unfortunately not reliably, because what you get in that case (duplicate cookies, or one cookie masking the other) varies across browsers. The only way to know for sure is to try to delete it and see if it's gone. – bobince Jun 28 '12 at 11:33
  • "_The only way to know for sure is to try to delete it and see if it's gone._" Could an active attacker constantly recreate it? – curiousguy Jun 28 '12 at 12:39
  • 1
    "_because what you get in that case (duplicate cookies, or one cookie masking the other) varies across browsers_" this suggest putting a nounce in the cookie key; it doesn't directly help for related domain cookie injection, but at least **injected cookies will not hide our owns**; we still have to find which cookie is the good one (the cookie key and value will not give this information) – curiousguy Jun 30 '12 at 13:46