Subscribe via RSS

Stealing Cookies

No, Not Like The Cookie Monster

January 1st, 2008 last updated March 23rd, 2010

After reading an article on 0x000000 which addresses using user-built webpages set up as subdirectories (not subdomains) to steal cookies set by the main website. I immediately thought of the personal webpages Willamette allows you to set up at as a student. A website which didn't take such risks into consideration would allow any user of the system to capture all the cookie data the real website is using, most notably PHP Sessions. Sadly Willamette uses HTTP authentication instead of cookie or Session based authentication so (at present) I can't capture anything of value. The only cookies I've so far seen set are cookies for Google Analytics. So at the moment Willamette seems to triumph over this particular hack, but there are countless schools out there which allow users to create their own webpage under the school's domain name with PHP, so I thought I'd let you all have a go at snagging the cookies of hapless visitors to your school's website.

Simply put this code in a PHP file and include it somewhere in the pages of your personal website and you'll get an email whenever you capture someone else's cookies (mail isn't sent if the only cookies found are Google Analytics cookies). Best of all would be if you caught a PHP Session cookie, such as a cookie named SID or PHPSESSION or the like. If you do manage to catch something, modify your cookies (using the Web Developer Toolbar Firefox Add-On, or something else) to their values and, hopefully, you'll be in! Let me know if you manage to pull something off, ok?

On another note, I modified the code for the blog slightly, giving rise to permanent text links to certain articles. Currently every article is identified by it's ID number, which is fine, but not very user friendly. Now, if I want, I can add a Permanent Link which will map a link such as which is a lot more friendly and explanatory to look at, no? Any article with a permanent link, such as this one, will have a [Permanent Link] link at the bottom of the entry. I'll primarily use this feature for articles which I expect to update or reference back to on any kind of regular basis, like this one, which is still a work in progress.

Also, I was playing around with cookie data and tried deleting the Session cookie my site sets then submitting POST data to a page protected by the authenticate() function, which returned a 406 error. 406 you say? I've never even heard of it, so I head over to wikipedia, and lo and behold, 406 doesn't even have a description! Far stranger than the error code itself, however, is how the information was formatted. If you've ever gone to a nonexistent page on my site before, you'll notice that it's still wrapped in the site's template and has a link to contact me if the problem persists. This 406 error seems to have been so low-level it not only didn't go to my custom error pages, it didn't even properly go through Apache's default ones. Look, here's the whole content of the page:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <HTML><HEAD> <TITLE>406 Not Acceptable</TITLE> </HEAD><BODY> <H1>Not Acceptable</H1> An appropriate representation of the requested resource /blog/admin/ could not be found on this server.<P> </BODY></HTML>

Isn't that strange?

Well it's late, and I'm tired, so I'm off. Hope everyone had an excellent new year!


Sadly Willamette doesn't seem to use cookies to store any kind of useful site-wide data. I know certain subdirectories and subdomains (such as Blackboard and the Class Register) use cookies, but those are not accessible from my personal home page. How sad. Nevertheless, the concept remains quite interesting, and I'd love to hear if anyone at other schools manages to steal anything useful.

New Comment

Your email address will never be displayed or shared. Your comment will appear once approved.