Cookie Forcing - Trust your cookies no more

Cookies are most often used to simply hold and exchange the session id with the application server. However, in some cases an application decides to implement a custom cookie. We all know this is generally a dangerous idea because the user can easily tamper with their cookies.

But, did you know that any attacker can easily tamper with your cookies too? In fact, an attacker executing an HTTP based man-in-the-middle attack can edit any of your cookies for any site? This includes cookies that have been marked "secure" or are set and exchanged with a site purely over HTTPS.

What does this mean?

• Cookie integrity is dead. Any cookie can be modified by an attacker without any warnings to the user.
• Custom cookies must now be eliminated. Any predictable information in a cookie could be modified by an attacker to cause undesirable results for the victim.
• Cookie confidentiality is still secure. This issue allows an attacker to modify your cookies, but does not allow them to view your cookies.
• This attack is an HTTP MitM attack. This is important because there will not be any certificate error messages to the user, this attack is nearly undetectable.
  

I have to admit, I didn't discover this issue on my own. I stumbled upon it one day here. I couldn't believe this item had slipped by with little discussion for the past year. In my disbelief I setup a few test cases in IE8 and Firefox 3.5 to confirm it is true.

To fully illustrate the issue, take a look at this chart I put together. A few things to note:

• The man-in-the-middle never attempts to be in the middle of HTTPS traffic. That traffic stream is left untouched.
• The MitM simply waits for any unrelated HTTP request from the victim (your browser sends plenty of these for updates, google prediction searches, or any unrelated browsing by the user)
• The MitM intercepts and responds to an HTTP request with a meta refresh to the HTTP page of the site of the cookies to be attacked (http://bank.com in this case)
• The MitM then intercepts the HTTP request and responds with the set-cookie statement.
• Here is where the magic happens. The browser happily accepts the set-cookie statement from HTTP even though the cookies are marked "secure" and had previously been set via HTTPS.
• In the last step you'll note that the MitM cookie is now active for the victim.

Potential Solution:
Change browser behavior to disallow HTTP set-cookie messages to modify cookies that had been originally set via HTTPS set-cookie message.




-Michael Coates