ChrisDevBox

Cookies are great, I eat them all the time, however, this article is about a different type of cookie. Browser /HTTP cookies. The big question is: Are HTTP cookies good or bad. I keep getting this question from non-techy people and some techy people “think” they know the answer… (Including me! jk)

I don’t have the right answer, but I’ll clarify things for you, and then you can make your own judgement whether cookies are good or bad.

Is really how you used them. In the hands of a sloppy programmer HTTP cookies can be VERY bad, but if you are a good and detailed-oriented programmer, cookies are going to be VERY good (sometimes!)

“The term “cookie” is derived from “magic cookie,” a well-known concept in UNIX computing which inspired both the idea and the name of HTTP cookies”. - Wikipedia In a nutshell, cookies are text files stored in your computer containing data that’s typically set by a server.

In order to truly understand cookies you also need to understand HTTP packets and a little bit of how the internet works. I’ll cover a little bit of everything here.

So cookies are text files stored in your computer, but how do they get there? First let’s understand how browsers work:

1. Type URL: User types a domain name like www.google.com
2. Browser makes a DNS lookup via your OS to get the “REAL” location of google.com. If you are using windows, like most of you are, you can see your DNS cache by running the following command: ipconfig /displaydns You can flush it if you like, just run iplookup help for a list of commands.
3. Internall DNS lookup will return an IP address (What’s an IP address?), is like you looking up a business “Pizza Hut” and finding the “REAL” address. Now we have the “REAL” address of google (For your area)
4. Browser (via WinSock / if using windows) will execute an HTTP GET (or POST, HEAD, depending on what you are doing) against google.com’s IP address. What is that mean? It means it will send a packet to the server hosting google.com. Example:
5. GET http://www.google.com/ HTTP/1.1
6. Get data: The server then returns the body of the document index.html from the server. You can actually copy+paste the above request (#5) inside a telnet session and it will do the same. On any type of shell/dos command prompt you type: telnet google.com 80 and then copy+paste the line above and hit enter a couple of times. Pretty cool huh?
7. Render: Finally! the browser renders the HTML (That’s a whole different topic). So now you should see the google home page. But what does this have to do with COOKIES!? Well a lot… see below.

Now that you understand how browsers work, let’s dig deeper (Ohh yeah, digg this if you like it).

Between “Get data” and “Render” (#6 and #7) there are a few things that happen in the background without you even knowing. This is where cookies are born or placed in the oven.

Ok this is what happens:

Read Response: When the server sends the index.html document back to the browser (or client) it sends a set of instructions and additional information about the server called HTTP Response. For example, if I did a get on google this is what I get.

HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Date: Thu, 12 Jun 2008 22:24:20 GMT
Expires: -1
Content-Type: text/html; charset=ISO-8859-1
Set-Cookie: PREF=ID=43d956b23a80fb8d:TM=1213309460:LM=1213309460:S=TeCN3DjIy3-qWAzZ; expires=Sat, 12-Jun-2010 22:24:20 GMT; path=/; domain=.google.com
Server: gws
Content-Length: 0

Note: You can see the above example by doing the following, type telnet google.com 80, then type HEAD http://www.google.com/ HTTP/1.1. Is works like MAGIC!

Ignore everything except for “Set-Cookie”. That line tells the browser to store that data inside a text file in your browser’s temporary folder (on windows xp C:\Documents and Settings\csanz\Local Settings\Temporary Internet Files), so google can access it later. Those values seem pretty cryptic, but I could still tamper with them if I wanted to.

So this covers ALL the basics… browsers, cookies, packets, server response, etc. so back to cookies.

Cookies are used for keeping user information, so let’s say when you log on to wellsfargo the server needs to remember your identity in order for you to navigate your account, so wellsfargo drops your personal ID inside a cookie.

Now start thinking like a hacker… hmm the server sends a response similar to the one above with the SET-Cookies info. Let’s pretend wellfargo hired a very sloppy programmer, this is the kind of response you would get from his login form:

Set-Cookie: username=chris;password=test

So your own cookie info would travel through the web in clear-text. Hmm very bad. So how would you tamper with that? (hack) Before jumping into hacking mode let’s try to make the request using the info above first

GET http://www.wellsfargo.com/myaccount/ HTTP/1.1
Cookie: username=chris;password=test

Note: This is just an example, if you try the above it won’t work.

The above request returns your account info from the server, basically wellfargo’s account info home page, you can navigate any other page using this info.

Now, are you still thinking “How is that bad?”. If you are then you need to keep reading.

Before I go on wellsfargo is extremely secured, so this is not an issue for them. They use secured socked layer (SSL), so the info above traveling back in forth looks like this (@#$@#&^*^*^DSFSDFKJLDF), very hard to decrypt. Wellsfargo customers you are safe.

Ok, let’s continue with the example. Let’s say I wanted to access someone else’s account info. How would you do it with all the knowledge you have now?

You do the same request with many different combinations of users names and passwords until you hit the jackpot. BUT, you do not do this manually of course, you write a program. I’m not saying that I would do it *wink*, but this is what a hacker would do.

So how do you prevent the above situation from happening?

Well you have many options, but these are the ones I recommend:

• Use SSL, specially if you are handling credit card info OR
• Encrypt your cookie values, makes it hard for hackers to tamper your cookie values

So that’s the mistery behind cookies. So your best bet is to stay away from smaller and obscure websites when it comes to sharing private info like your credit card, social security etc.

The site itself may not be the bad guy, but if they have a sloppy programmers they “may” be vulnerable to sloppy code and smart hackers.

That’s it!

This entry was posted on Thursday, June 12th, 2008 at 6:09 pm and is filed under Hacks, Security.