Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

  (email not shown publicly)
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Friday July 18, 2003
01:43 PM

Friendster Security Hole

[ #13542 ]

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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Through back-channels (Friendster is local), I learned that they have ~40 boxes running Tomcat, and that they have substantial performance problems in-and-around data replication.
    • Re:Friendster (Score:3, Interesting)

      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.

    • 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.


    • I post it to 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! .

    • 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 b