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

Improve this question
5
  • 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.
    Commented Mar 6, 2012 at 21:04
  • @D.W. I renamed it to "same domain cookie attacks"... how does that sound?
    – makerofthings7
    Commented Mar 6, 2012 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.
    Commented Mar 7, 2012 at 0:23
  • 1
    @D.W. Ahh, related domain cookie attacks makes a lot more sense then what I wrote there before!
    – makerofthings7
    Commented Mar 7, 2012 at 1:14
  • Do we need a vulnerable-by-design tag?
    – curiousguy
    Commented Jun 30, 2012 at 13:56

1 Answer 1

Reset to default
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.

Improve this answer
4
  • "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
    Commented Jun 27, 2012 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
    Commented Jun 28, 2012 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
    Commented Jun 28, 2012 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
    Commented Jun 30, 2012 at 13:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .