Slashdot Mirror


HTTPS Cookie Hijacking Not Just For Gmail

mikepery writes with a followup to last month's mention of a security vulnerability affecting Gmail accounts, which it seems understated the problem. "I figure the Slashdot readership is the best place to reach a large number of slacking admins and developers, so I want to announce that it's been 30 days since my DEFCON presentation on HTTPS cookie hijacking, and as such, it's now time to release the tool to a much wider group. Despite what was initially reported, neither the attack nor the tool are gmail-specific, and many other websites are vulnerable. So, if you maintain any sort of reasonable looking website secured by any SSL certificate (Sorry Rupert, you lose on both counts), even if it is just self-signed, you can contact me and I will provide you with a copy of the tool. Be sure to put 'CookieMonster' in the subject, without a space." (More below.) "I'd also like to encourage security professionals and consultants to request a copy of the tool for use in encouraging their clients to adopt SSL properly for their websites. There's no possible way for me to reach every site, but if convincing demonstrations can be given of the vulnerability on an individual basis, perhaps that will drive the issue home much more than the press alone has done. Heck, the tool might even land you a few new clients."

9 of 128 comments (clear)

  1. Re:Easy to find out... by pragueexpat · · Score: 5, Interesting

    if this is true (and I am able to follow directions correctly) then Bank of America has some explaining to do.

    --

    "The prohibition will be strongest when the group is nervous." - Paul Graham

  2. please tag itsatrap by sveard · · Score: 4, Interesting

    Why don't YOU just e-mail the guy and be done with it?!

    Perhaps it's... A TRAP!

  3. Comment removed by account_deleted · · Score: 2, Interesting

    Comment removed based on user account deletion

  4. Re:yeah... by PJ+The+Womble · · Score: 2, Interesting

    I think Franklin ahref=http://sln.fi.edu/franklin/scientst/electric.htmlrel=url2html-25902http://sln.fi.edu/franklin/scientst/electric.html> might have disagreed vehemently with you. Air breaks down as a dielectric, given a high enough voltage across it. And, of course, electromagnetic radiation of all kinds goes right on through air as if it wasn't there. And don't get me started on sound ;-)

  5. Re:Easy to find out... by HungryHobo · · Score: 2, Interesting

    I can get you there.
    My ISP assigns me a new IP every few minutes even if I'm in the middle of a download. Makes using rapidshare impossible.
    And yes, there's always the jackass developer who thinks he's smart locking sessions to an IP which for me just means either being logged out again and again or it locking up till the link to the old IP has expired.

    Yes I know it's the ISP but they're the only game in town and I'm not going back to 56K

  6. Re:new security vulnerability by Anonymous Coward · · Score: 2, Interesting

    i'm thinking cm is "contact me", so contact me via the fscked organisation

  7. Comment removed by account_deleted · · Score: 2, Interesting

    Comment removed based on user account deletion

  8. How do you secure a site? by JoeCommodore · · Score: 3, Interesting

    There were a lot of 'email me's and talk about bad htps settings but not much content on really what needs to be done for fixing an existing site or properly setting up a new site to be secure.

    --
    "Enjoy what you're doing! If it becomes drudgery, you're doing it wrong!" - Jim Butterfield
  9. Re:Easy to find out... by mcrbids · · Score: 3, Interesting

    I did this with our own web-based product and found out that yes, indeed, we are insecure. It took a few minutes of poking around to find out how to secure our site.

    So, for everybody else: if you are using PHP, you need to pay attention to Set_Cookie_Params() . Here's the 1-liner call that we make in order to solve this problem for us, before any calls to session_register():


    Session_Set_Cookie_Params(720, '/', $_SERVER['SERVER_NAME'], true);

    Parameters:

    1) 720: Our sessions timeout after 2 hours.

    2) '/': the cookie applies to all paths within our site.

    3) $_SERVER['SERVER_NAME']: applies only to the specific domain name originally called. (we use subdomains, so this is important)

    4) true: (the most important one), this means that the cookies can only be used over SSL.

    --
    I have no problem with your religion until you decide it's reason to deprive others of the truth.