Over a quite long time (2006 to 2014 that is) I was operator of a web server, ikaria.informatik.uni-rostock.de. Among other logs, I regularly reviewed the web server log. Most of my users were students, but since advent of one-click hosters and free webspace became available literally everywhere, it was arguably relaxed. However, some day I noticed a student had put a graphic file on my webspace which was used as signature in some forum. That made me think of what one could do just with this little piece of information. And then I found some little extra, I didn't expect to find in the wild.

The general thing with referenced files being included

What exactly is to be found in the log file? For all those who never digged into an apache log, each request is logged in a line of its own, each line presenting the following columns:

Client-IP - Username - Timestamp "Request Path HTTP-Version" Response-Code - "Referrer" "Browserkennung"
Yes, this is just the vanilla default, I kept it that way. Surely you can configure it to carry much less information if you care about privacy. Honestly: I cared more about being able to reconstruct an attack if there would have been one. Well, some day I noticed a request to a single image file whose referrer pointed to some forum. And that got me thinking. Which information can I (as operator of a web server which provides some signature picture) gather? This is my list:

The reason I write about them

Up to this point, this article has been a mere remake of some general purpose text on web bugs/counting pixels; except the fact that I do not employ them actively.

The inside scoop

If you create a web application which under any circumstances is able to include 3rd party resources, be aware of what they'll see as referrers. And don't encode sensitive data in URLs which are.. well, just not made to carry sensitive data. Thank you.

Update 14.08.2015

As sometimes with long-term-memories, I messed up a bit. The URL-encoding of the session identifier was not used by default by that fucked up, crappy, weak excuse for a software. It was only used when the user decided to disable cookies which were used by default. While this seems to be a nice idea in the beginning it's perhaps even worse if you take a look at which kind of people tend to disable cookies. Those who want to put a little extra privacy on their browsing habits. Cudos to the developers for turning "a little bit more privacy" into "we hand out your current session to everyone who's near."

Oh and another postscriptum. I got asked how the password shall be changed if an attacker has just a vaild session identifier but no clue of the current password which is needed for password change. That's simple. Just change the user e-mail address in the profile, then logout and go through the "I've lost my password"-procedure. In 9 of 10 implementations, the password reset procedure will send the user a mail with a special link to a site which lets the user set a new password. The remaining 1 implementation which doesn't do that is broken.