AppSec Blog

Logging Cookies and Ambushing Lazy Pentesters.

Logging is probably one of the dry topics in application security. Without logs, debugging or even incident handling is soo much more exciting! One of the little Apache tricks I learned is to log cookie information in your Apache log. The cookie typically includes the session ID, which then links to a particular user. So this way, you can figure out which user caused a particular action. Yes, in many sites you can just use the IP address and the time stamp. But this is more labor intensive and not as accurate. It only works well in sites nobody actually visits. Apache typically logs after the complete page is served. Your own application logs however are written (and I hope you do have application logs!) while the page is created. There may be a few seconds difference which can be a pain to link up if you have a few hundred hits a second.

So here is the little added logging directive:

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\"
\"%{User-Agent}i\" \"%{Cookie}i\"" withcookies

Here I just used the "combined" log format, and added the cookies to the end. You can add any request header using the "%{headername}i" scheme. The quotes have to be escaped if you use double quotes to enclose the header. Now to actually log using the header just add

CustomLog /var/log/httpd/access_log withcookies

You probably already have a line just like this using the "combined" or a similar format. Make sure your log analysis tools know how to deal with custom log formats.

But this is the "Streetfighter" blog, so lets take this idea a notch further. Many pentesting classes ask pentesters to look for "bad cookies". This is session information that should be kept on the server but is too often kept in a cookie. For example, the userid. Pentesters are aksed to look for cookies like "userid" and see if the value matches their userid. If so, they will next try to modify the userid. Well, we got a surprise for them:

We do set a "userid" cookie, and you may even set it to the users userid, but you essentially ignore it. You only check if the cookie's content matches the actual userid stored in the session. If not... give them a good kick. I like to disable the account for 30 minutes. It sure slows them down. If it was a real hacker: Remember the old hiking rule: You don't have to outrun the bear, you only have to outrun your hiking buddy. A little trick like this can make your side too much of a hassle to attack and they will move on to a simpler site. Lots of vulnerable sites to go around!

(In some cases, you may have false positive issues if your site's users are in particular playful. But then again: They shouldn't "play" with your site. You may just want to trigger a log entry to catch excessive abusers)


Posted May 26, 2009 at 4:07 AM | Permalink | Reply

Jim Manico

This is terrible advice. Logging a session id is a anti-pattern that should be avoided. You want to avoid session hijacking from the inside. A session id is almost as valueable as a password.

Posted May 26, 2009 at 5:17 AM | Permalink | Reply

Johannes Ullrich

I agree that a session ID is almost as valuable as a password (plust username). Actually my advise typically is to treat it like username and password (e.g. that's why you need to send it over SSL..). But'' how do you actually prevent session hijacking "from the inside"? The web server has to know the session ID. The web server does not need to know the password (it only needs to know the hash of the password). I usually feel that it is better to limit the usefulness of the session ID by rapidly changing it. But my main concern are attacks from the outside and I need useful logging to fight them.
So point taken. Maybe log last few digits of the session id? A hash of the session id? (but then the simple cookie logging trick doesn't work anymore).

Posted May 26, 2009 at 8:39 AM | Permalink | Reply

Jim Manico

Honestly, I think you should hash the session id if you need to log it, at the very least. Anytime you start logging credentials, you really need to think twice.

Posted May 26, 2009 at 8:25 PM | Permalink | Reply

Ivan Ristic

By the way, the discussion spilled to:

Posted May 28, 2009 at 12:45 PM | Permalink | Reply

Jim Halfpenny

One interesting side effect of the default Apache mod_usertrack cookie is that it's uniqueness is partly based on the client's IP address. I've has situations in the past where I've been able to link the origin of malicious activity from one event to another by this value. Without logging the cookies this would have been missed.

Post a Comment


* Indicates a required field.