Cookie viruses? Me thinks not


The only reader of mine had a question: what is my opinion about cookie viruses? (If you also read this blog, I apologize and also I’m werry happy in this case that I have more than reader. If you have questions or topics you would like me to discuss, please post them in the comments)

Getting back to the topic here: I don’t have an opinion, since there is no such thing as a cookie virus. By definition the a virus is (quote from Wikipedia):

A computer virus is a self-replicating computer program written to alter the way a computer operates, without the permission or knowledge of the user.

There is no such thing because cookies should be (and usually are) treated by browsers as opaque tokens (that is they are not interpreted in any way and are sent back exactly as received to the server). Now one could imagine the following really far-fetched scenario which would be something similar to viruses:

A given site uses cookies to return some javascript which is evaluated at the clientside by some javascript embedded in the page (that is the code embedded in the page is looking at document.cookies and doing an eval on it. Now in this case we could make the client side javascript do whatever we want, however:

  • If we can modify the client side headers, probably we have very such access to either the client or the server that there are much more malicious things that we can do.
  • The javascript will be executed in the very limited context of the web page, so we could only infect other cookies that go to the same site (but we already had access to it when modifying the first cookie, so there is no reason for using such a convoluted method.

Now many sensationalist sources use the word virus to refer to all kind of malicious actions to drive up hype (and we all know what my opinion is about that). There are however some real possibilities of doing harm, most of them in the area of information theft and input validation.

  • The first one (which doesn’t fit in any of the two mentioned categories) is the possibility that there is a buffer overflow exploit in the cookie handling code at the server. In the official standard it is stated that a cookie should be now larger than 4096 bytes and we all know that when something like this is in the spec many coders automatically write char buffer[4096];. However before you think that this is a 0-day against Apache or something, let me say the following: I threw together some quick code an ran it against an Apache server (2.2.something) and it very nicely refused to accept the headers. It also generated a return message which was properly escaped, so there is no possible XSS vulnerability there. I’m also sure that IIS has no such problem but maybe some home-brew custom http servers might have this problem.
  • A scenario on which some papers are focusing is the following: the cookie contains some text which is relayed back to the server, which in turns embeds it in the HTML output without proper sanitization. This can result in the attacker embedding code of their choice in the page, including javascript, however such an attack has no real-life benefit, since if the attacker can access the clients cookies, s/he has probable write access to the file system and can do much more nefarious things with much less complication.
  • A third possibility would be that the server relies on data contained in the cookie for authentication or for some other action. In the first case there are two vulnerabilities: cookie theft and creating a custom cookie to gain access (if the server relies for example on some value to be present in the cookie to indicate that the user authenticated successfully). The second case would be when there are parameters in the cookie for a server-side process (shopping cart information). If the server has no way of validating the information upon receiving it or doesn’t do so, one could manipulate this information to gain advantages (to buy things at a 0 price for example). Ideally this information should be kept in a server-side session storage or if you don’t want to break the REST model, encode it in the URL, but make sure that you provide a way for the server to verify the posted back information, by for example encrypting it and then appending a salted hash (where the salt is only known to the server) to it and verifying this when receiving a new request.

In conclusion: Developers – validate your input! validate your input! validate your input! (at every step)

, , , , ,

3 responses to “Cookie viruses? Me thinks not”

  1. Hi,

    Your only reader is back lol. I’m sure i’m not though !

    Actually i was wondering about the possibility, however remote it may seem, of Any malicious cookie manipulation in whatever way/s, rather than just viruses !

    It appears it can be done to some extent from what you say, even if there are easier methods of infiltration etc via other means through other vectors.

    But as the cookie file/s can be written to, if javascript or some other code was placed in there, could this possibly be made to cross feed or jump to other areas of the disk etc, under Any circumstance ?

    Say if some code/url etc was placed there on one visit to a www, then on return this was used with other code to initiate some kind of attack or data theft or a redirection to a Trojan dropper download www etc for eg ?

    Yeah i know i’m speculating, it’s just ideas as to what may be possible under certain conditions, eg with or without ActiveX/Scripting/Jave/Iframes enabled etc.

    I feel that as baddies are always looking for new/old ways in, this could be an overlooked area in some ways ?

    Thanx for your time and input,

    Spanner

    SpannerITWks

  2. Some theoretical possibilities:

    -the browser has an exploitable bug in the cookie handling code (probability: very low, damage potential: critical – would result in arbitrary code execution).

    -the browser has a bug which allows sites to set cookies for other domains (probability: very low, damage potential: medium/high – could result in cross site scripting attacks if the target webpage has poorly written code)

    Again, much hype has been created around cookies (mostly by the anti-spyware vendors), but they are treated by browsers as opaque things (they are not interpreted in any ways), so the possibility that a malicious use can be found which would work across browsers is very, very low. (The possibility of an exploit is also very low, since it is a simple thing to implement).

    My opinion is still that this is too convoluted 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *