Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Here, several servers in the same DNS domain emit cookies under a variety of settings (scope, HTTPS, Secure) and another host emits a cookie with the same value.

Example

Suppose a user has the following cookie set at secure.example.com:

 authCookie = SomeSessionToken (Scope example.com, Secure, HTTPOnly)

Then the user goes to a blog.example.com that is compromised (perhaps in another tab). It sets a non HTTPOnly cookie like this:

 authCookie = AlternateSessionToken (Scope example.com, Secure, not-HTTPOnly)

Would the next request to secure.example.com use the alternate credentials?

Is this scenario possible?
--Will the browser set two different cookies(with the same name) for two respective servers?

--Or the authCookie gets overwritten?

share|improve this question
    
See also: How can we protect ourselves from cookie attacks ... the answer is that there isn't a solution. TLS-OBC is a potential RFC candidate that may fix this –  makerofthings7 Mar 16 '12 at 16:20
    
"a non HTTPOnly cookie like this:" non HTTPOnly, or HTTPOnly? –  curiousguy Jun 28 '12 at 0:03

1 Answer 1

up vote 25 down vote accepted

Summary. Yes, this is possible. It's not a browser bug. It is part of the as-designed functionality of cookies. There is no browser that is safe from this. Cookies are ancient technology and their security model is only loosely-integrated with the rest of the web. The details are messy and ugly.

The gory details

The site blog.example.com can set cookies with scope blog.example.com or with scope example.com. Cookies with the latter scope will be sent back to secure.example.com, if the user visits secure.example.com.

If the site secure.example.com sets a cookie with scope example.com, then the site blog.example.com can overwrite that cookie arbitrarily. Whenever browsers see a cookie with the same name and scope as one that's already in the cookie jar, they discard the old cookie value and overwrite it with the new cookie. Thus, blog.example.com can overwrite any cookie whose scope is example.com.

Worse still, one cookie can shadow a cookie with another scope. Suppose secure.example.com sets a cookie with scope secure.example.com and name SESSIONID. Next suppose blog.example.com sets a cookie with scope example.com and the same name. Finally, suppose the user visits the site secure.example.com. What happens? It is ugly: the browser sends both cookies, in some undefined order, and the server has no reliable way to tell which cookie value came from which site. So, the server can detect that it is in a confusing situation, but has no good way to unconfuse itself. Worse, some web application frameworks may conceal the confusion from application code, using one of the cookie values and silently ignoring the other. This can lead to something that behaves effectively like blog.example.com overwrote the cookie from secure.example.com, in a situation where no one would reasonably expect that it might be able to.

(As a side note, the secure flag does not prevent a cookie from being overwritten. In fact, a HTTP site can overwrite a cookie with a secure flag, as long as the domain names are related appropriately. The secure flag provides confidentiality protection but not integrity protection.)

Finally, there is one other way to delete cookies: a malicious site can set lots of cookies, overflowing the fixed limit on the number of cookies that the browser will store. The result is that the browser "forgets" older cookies from other sites. This allows blog.example.com to delete all of the cookies set by secure.example.com (regardless of their scope), and then set a new cookie with scope example.com that will be sent back to secure.example.com -- which has much the same effect as overwriting an existing cookie. This may be what you were thinking of when you mentioned "cookie jar overflow".

Discussion

It's messy. Sad to say, this is just how cookies work on the Internet. If you want to avoid it, the simplest defense is to use a new second-level domain for untrusted sites. There's probably a better defense that doesn't restrict the naming of your sites, but I don't know what it is.

As a general note, for questions like these about how the web works, I highly recommend the browser security handbook. It is packed with nuggets. In this case, you might want to read its material on the same-origin policy for cookies.

share|improve this answer
1  
+1. Great explanation. Are there similar concerns with cookie paths on a single domain? If a cookie is set on /subfolder path then it's not accessible from the root of the domain or another sub-folder, but can the same attacks methods be executed in this case? –  Yoav Aner Mar 5 '12 at 8:56
    
Thank you; I think this has implications for Active Directory... your advice on the linked question is appreciated –  makerofthings7 Mar 5 '12 at 9:57
1  
@YoavAner, my understanding is that you should not count on the path to provide any extra security. For instance, Javascript from a site S can read all cookies for S, regardless of path. –  D.W. Mar 5 '12 at 18:15
    
I'm thinking of keeping this Question open longer to see if there are any servers that detect or are immune to this. (Some HTTP Handler might detect two cookies with the same name) Is that a valid idea? –  makerofthings7 Mar 6 '12 at 14:36
1  
You can prevent some attacks by digitally signing your cookie content with a different private key for each individual application. This would allow you to detect when a cookie had been tampered with, and thus reject the request on the server side. This can be done without any special browser support. It would not help you at all with a cookie being "deleted", and you could also potentially still be vulnerable to replay style attacks. –  Nathan Jul 16 '13 at 17:42

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.