$ENV{'REMOTE_ADDR'}.$ENV{'REMOTE_PORT'} are not actually being used in the cookie itself. They, along with the salt and the process id ($$) are merely being used with Digest::MD5 to increase the likelyhood of generating unique session ids. In retrospect, I suppose that I should also throw a randonly generated number in there.

We are not using the server's built in authentication and session tracking because we hope to reuse this code on different sites and cannot guarantee which server we'll be using. This seemed like a more portable approach.

As for the contents of the cookie being spoofable, guessable, and tainted:

• Spoofable:

  If the digest in the cookie doesn't match what's in the database, they simply get redirected to the login.

• Guessable:

  To guess how to generate the digest, they'd have to figure out the salt, which I think is non-trivial. If they sniff it, they could possibly hijack a session, but that's why the digest is changed on every access. They attacker would have to sniff the cookie and submit it before the user clicked on another link (this is the big weakness of not having everything over an SSL connection). If they do sniff the cookie and don't send it soon enough, either a new digest will be in the database or the database-controlled session timeout will block them.

• Tainted:

  Shouldn't matter. At no point is anything done with the cookie data except check to see if it is the same as what's in the database. Oh, there is one exception: it's included in an SQL statement for clearing old sessions, but even then a placeholder is used in the SQL to ensure that it's properly quoted.

Cheers,
Ovid

Vote for paco!

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.