Wandering Thoughts archives

2006-08-25

Please don't use session cookies

Recently I have become quite irritated at a couple of websites that I visit regularly. See, they have a membership system, and I'm a duly paid member (I like them and it has some benefits (that I rarely use)), and they recently switched to using session cookies for logins. Which means that every day when I visit, I get to make a time-wasting detour through their login page.

It's tempting to think that if you use session cookies, the users are 'more secure' than if you give your cookies an explicit expiry time because they will expire sooner. This is clearly false: as implied by the name, session cookies last for the entire browser session, however long that is. It could be minutes, but it could also be weeks (and yes, I know people who keep their browsers around that long, myself included).

(RFC 2965 session cookies can have an explicit expiry time, but I don't know how widely they're supported. Original style session cookies are created by omitting the expiry time when you set them (cf RFC 2109).)

If your security needs really require people's sessions to expire relatively rapidly, you need to do this on the server end: have a maximum idle time or a maximum duration (or both). You can use session cookies too, but you should consider them only an extra bit of safety for the user.

(Hint: if you think your security needs require this and you are not using https, I am going to laugh at you.)

In fact, if your security needs require people's sessions to expire at all, you need to use explicit timers (on your end). Otherwise you might as well serve up persistent cookies with a conveniently large expiry time. (DWiki uses a year.)

One reason to consider using session cookies

Apparently, some people and some browsers are more willing to accept session cookies than persistent cookies (an issue brought to my attention by Tom Boutell).

However, if you're using session cookies for this reason, please send both a session cookie and a persistent cookie, and consider the user logged in if you see either cookie. That way you are not inconveniencing the people who are willing to accept your persistent cookies.

(If you see only the persistent cookie, don't try to reissue the session cookie; it's pointless and will annoy the user in some browser configurations.)

web/NoSessionCookies written at 16:26:18; Add Comment

Another stupid spider mistake

To follow up my earlier entry on this stuff, I just saw another stunned monkey moment:

  • you can't randomly add a trailing slash to URLs any more than you can randomly remove them.
  • especially when the URL includes a query parameter, because then you're changing the query. And that always works really well.

From the pattern of the stealth spider's requests, I think it is adding the trailing slash on any URL that doesn't end in a filename with an extension. This is stunningly braindead, as extensions are nothing more than a hack workaround so webservers don't need real metadata about what MIME type a file is.

(It also has other problems, like not properly resolving relative URLs that use '..'.)

This stunned monkey moment is brought to you by the idiotic stealth spider running from 204.11.99.2, which is claimed to belong to a 'Goo Khim Yeung' as 204.11.99.0/29. (Assuming that the WHOIS information is accurate, which it isn't always.)

web/StupidSpiderMistakesII written at 11:35:05; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.