Software, technology, sysadmin war stories, and more. Feed
Wednesday, November 2, 2011

Rogue cookies named BCSI-AC spotted

Quick quiz: who can set cookies for your domain?

If you started launching into an answer about matching domain names, and the special cases for two-letter country domains, and all of this, you're on the right track. But... you're not totally right.

The reality of the situation is that anyone who gets between your user and your web site can inject cookies. So you think, oh, right, sure, this is the evil attacker scenario. True. That is in fact one way it can happen.

There's also another way in which nothing evil is happening but they plant cookies in your namespace all the same. It's the "walled garden" situation.

I just discovered this recently. I've written my cookie-handling code for things like fred to only accept cookies which I had generated. I only generate hex digits, so anything outside of the usual isalnum() range is garbage and can be discarded.

So, imagine my surprise when my "bad cookie" code started firing. It was detecting characters which I would never put into a cookie. One of them starts "BCSI-AC" and then has a whole bunch of base64 gunk, including the usual = at the end. Some digging around suggests this is the side-effect of loading one of my pages on a local hospital's public network.

It looks like this particular example is someone's laptop which gets carried around. At some point, they loaded my site while on that network and got "infected" with the bogus cookie. Now, even when they're back at home, it's still being relayed to me.

The lesson bears repeating: you can never trust the client.