HTTP Header Manipulation Series Author: David Zimmer Site: http://sandsprite.com/Sleuth ----------------------------------------------------------------------------------- This paper is the second in a series dealing with http header manipulation. In the previous article we discussed what http headers are and the basic role they play in the context of a web application. In this section we are going to key into one of the specific data fields and discuss how it is used and why people may wish to manipulate it. The cookie entry is one of the http data fields that was mentioned previously. To fully understand its manipulation we first need a grounding into what a cookie is and what it is used for. To begin our adventure into understanding cookies we must also understand an often heard but seldom explained phrase , "HTTP is a stateless protocol". That is all well and good but what exactly does it mean? Well let me take you on a brief field trip into the workings of a web server and lead you to this phrase from the back side. When a web server receives a request for a page, the server itself doesn't know or care who you are. It has no idea where you have been, it is only there to serve you web pages. As the web server reads the page, it is up to the individual scripts in the web page to determine your identity and display the appropriate content. These scripts use data provided by the surfer (data sent in the http header) to determine your identity, where you have been and where you want to go. From this we can point out that it is not up to the HTTP protocol to worry about any of these things, it is merely the mechanism in which the data is presented to the scripts running on the web server. It is here that it is said that "HTTP is a stateless protocol". Http is merely a method of data communication.Avanced features such as user tracking and acknowledgement is the realm of the specific authors web pages that is working on the data they receive from the HTTP header. Today’s web applications typically need some way to keep track of who you are across requests. When you log in to check your email, you expect it to remember who you are and not require you to provide a password for every action you perform. Behind the scenes what is actually occurring when you login is that the web developer is giving you a token (like an id card) that certifies you as you. This token can take any form the web developer chooses but it commonly comes in the form of a cookie. When the browser receives a http header entry like this: -------------------- Set-Cookie: strUserName=dzzie;&strUserID=EN7048321 expires=Thu, 15 Apr 2010 20:00:00 GMT; path=/; domain=.yahoo.com -------------------- it interprets this as a command and stores the value and a reference to the page that set it. From this point on, when the browser requests a webpage from this server* it will also include this cookie** as an extra data field in the http header. Below is an example of a http header sent to a web application after login. -------------------------------- Cookie: strUserName=dzzie;&strUserID=EN7048321 -------------------------------- As you can see cookies are frequently used to hold the tokens of our logins and are used by the web developers to differentiate us from others. It is also worth noting that many web application developers know little or nothing about how the cookie actually works. From the developers point of view, they just need a mechanism to store data that works.. and hey, cookies work, so that is where I will store stuff! Furthermore because cookies are "hidden" away and out of plain site, it is common for them to think that they cannot be altered. Realizing that the cookie value is just a simple plain-text entry sent to the server you can guess that they are indeed trivial to alter. The question now turns to what would an attacker gain from cookie manipulation? Consider the above cookie. This cookie is a pretty straight forward list of the information collected about me from the site. This includes author specific fields such as the one called strUserId. If this developer thought that only he had access to this value, it is likely that he assumes the values are always correct and never cross checks the received data in anyway. Note that this cookie value is directly from my worklog of a security audit I preformed on a large complex site last spring that services anywhere from 2-7k surfers at any given time. Such logic is out there in alot of production code. In this audit I took the user id value, incremented it and requested a page that would indicate who I was logged in as. Magically I was greeted with a large "Hello Dwight!" proudly displayed at the top of the page. Congratulations it was that easy to steal another users login and access their full account. What else can cookie manipulation bring us? In the above example how did the web application know that user id's "EN7048322" name was Dwight? Dwight wasn't in the data passed into the request, so it must have found it elsewhere; most likely drawing it from a database. Working on this premise I went and entered some database unfriendly characters into the user id. The hunch was then verified by the server which emitted a nice Sql Server error message. The moral of the story is, any time you take actions in your scripts on user supplied data , it must be subjected to sanity checks, content filtering and integrity verification. In the cookie value example above, had the author cross-checked the user id to the email address provided he could have detected my ruse. Even with such a check in place this would have been the equivalent of asking for a readable username and password for every transaction the user performed which others may be able to access. As the above process was laid out, the developer was literally asking the web surfer to tell him thier identity without asking them to prove it, in his mind they had already proved it once and did not know that identity relied on easily manipulated data. Secure programming practices are outside of the scope of this article as is the discussion of Sql injection attacks hinted at in the database example. From here you should have a solid understanding of how and why cookies are used in the web application and how the data is actually exchanged between browser and server. Hopefully this background into the actual mechanism of cookie transfer will allow you to have a sense of how to securely use cookie values and what to trust to them.