Friendster, as some of you might know, is a beta version of an Internet service to allow people to create networks of friends. Someone invited me to join and while I was at first reluctant, I decided to check it out. The first thing I noticed was that it appears to be built using Java Server Pages. Naturally, my biases kick in and I was rather suspicious. Good thing that I was, too.
Aside from the fact that the service is terribly flaky (but it's a beta and they're overwhelmed, I can hardly fault them for that), it's instructive to examine the headers that they return. Specifically, taking a look at the cookie. Despite the fact that it returns a session id, it also returns my email and password in plain text.
When can't people get this right? Why isn't it blindingly obvious to people who do Web development why this is a bad idea? To compound matters, the allow me to remember my login. While I haven't tried this options, I assume this means that the expiration for the cookie will be set for some time in the future, thus ensuring that my password will be saved to disk. Better hope I'm not using a shared computer! Of coures, even if I don't accept this option, this data could still be written to the swap file.
And how do the ensure that their session cookies expire? They set the expiration for a year in the past. Hey, I haven't tried doing that before (for obvious reasons). I wonder if that will also save my cookies to disk. I suspect this behavior might be browser dependant.
In any event, if their cookie mismanagement is any indication of the rest of their code quality, I don't expect them to solve their stability issues any time soon.
Re:Friendster
Ovid on 2003-07-18T21:27:44
Well, I must say that I hope they get these issues ironed out. It's long been known that we can't predict the long-term effects of the 'Net and I think experiments like Friendster are exactly the sort of thing that I like to see while we try and flesh out the new future of communication. I would love to see them succeed.
Re:Friendster
Ovid on 2003-07-18T22:00:27
Interesting. The was down when I made my post. It's back up and now the password is no longer being sent. Curious timing, but I'm happy to see this
:)
Which also stores usernames and passwords in plain text in a cookie? Well, obfuscated, at least as much as basic-auth is...
Quite shocked me when I looked closely at my slashdot / use.perl cookies.
-Dom
Re:Why are you posting this to use.perl?
Ovid on 2003-07-19T20:23:53
I post it to use.perl.org for the same reason others post post plenty of other non-Perl things here: it interests me.
The comment about the use.perl cookie was interesting. I had suspicions about the cookie, but never looked at it that closely. If you really want fun, though, take a look at the full headers. You'll see things like: X-Bender: My full name is Bender Bending Rodriguez. and X-Fry: Hey look, it's that guy you are!
. Re:Why are you posting this to use.perl?
Dom2 on 2003-07-20T09:33:56
Sorry; I wasn't serious about the use.perl comment.As to the headers, I love 'em. First saw them on slashdot, and I'm thinking about adding something similiar to my latest project now...
-Dom
Re:Why are you posting this to use.perl?
pudge on 2003-07-23T00:07:28
FWIW: No usernames are stored, the user IDs are. And the MD5 hash of the password, not plaintext, is stored, which can be used to log in if you also have the user ID. Also, there is an option in your password prefs to not store the cookie information.
And you can always click "Logout" to delete your cookie, too.
As to the proper deleting of a cookie: setting the expiration date is the recommended method. In this Netscape doc, for example, it says: If a CGI script wishes to delete a cookie, it can do so by returning a cookie with the same name, and an expires time which is in the past.Re:Why are you posting this to use.perl?
Dom2 on 2003-07-23T00:12:17
Thanks for pointing that out; it had been a while since I'd looked at it, I'm guessing that it's been improved in recent versions of slash.-Dom
