locked
How secure are cookies, if you can just see them in the browser? RRS feed

  • Question

  • User435801899 posted

    Not really an ASP.NET specific question, but seems a good place to ask. In preparation for a business critical web application, I've been doing research into secure session management, in particular securely storing a session key as a cookie. The approach I intend to take is:

    * Session key includes 256bit from cryptographic strength RNG

    * Set cookie to "secure"

    * Set cookie to "HttpOnly"

    * Server forces HTTPS, with a valid SSL certificate

    * Cookie to expire on browser shut down

    * Cookie limited to exact domain

    * Server checks session key against original IP address (controversial and potentially problematic, but I think it will work in our situation)

    * No cross-site scripting (XSS) or user generated HTML/script in the entire application

    This seems to me to be about as secure as you can get for browser based session management.

    However I blathered fits and giggles when I realized that anyone can receive this incredibly secure session key just by going to Tools > Options > Show cookies (or equivalent).

    I dunno, but to me this sort of craps all over all these efforts to secure the session key. What is everyone's thoughts on this - is the key still considered secure, or are there further measures we could take to secure it?

    You could argue that if the user wanted to do this, there's nothing to stop them, eg. they could have executed the various HTTP requests manually and examined the results to get a session key. But still it just seems so.... easy. The session key is essentially a temporary password, and there it sits in plain text just a couple of clicks away.

    Cheers,

    -Brendan

    Monday, June 14, 2010 11:04 AM

Answers

  • User-861155893 posted

    if they have access to your box directly session cookies are the least of your issues. And SSL does not protect you against MITM... consider:

    jane visits banking site but unbeknown man in middle captures banking SSL cert. MITM sends fake SSL to jane which causes popup about unsecured SSL (only drawback). She accepts, janes 'encrypted' traffic is sent to MITM who can then decode, and his 'ware' then encrypts and sends using original real ssl cert...

    are your arp caches hardened?... all your usb ports, ethernet ports, etc secured?? if not then you are not secure against spoofs. Your users educated on social engineering? password policies?... no system is secured unless it is unplugged.

    BUT. in any Sec Policy you have to balance productivity against security.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, June 14, 2010 8:37 PM
  • User-861155893 posted

    I think really if you want to secure then you have to employ a variety of techniques (layered sec)...

    it is a tough one though... the higher the value of the data the more attention you must pay. unfortunately you build up the walls and if the incentive is high enough someone will try bring it all crashing down (and most likely will succeed eventually)

    A good discussion on session stuff is in php man pages

    http://www.php.net/manual/en/session.security.php

    great topic though... any MVPs have any advice?

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, June 14, 2010 9:05 PM

All replies

  • User-861155893 posted

    ... you only give session keys to people you have identified... so what does it matter if they see their own session key?

    It's correct that this is a temporary password otherwise for every request you would have to prompt them for their credentials

    And finally - your main issue in browser session handling (and what I think you are alluding to) is "What happens if SOMEONE else gets that session?". Research session hijacking. Theres very little you can do to control this (unless you maintain the clients network and have security measure to stop packets sniffing and ARP poisoning)

    Monday, June 14, 2010 4:47 PM
  • User435801899 posted

    No problem with users seeing their own session key, just problem with anyone else spotting it. I'm thinking of someone walking up and stripping it out of the cookie cache, or, a browser storing it in an insecure way (on disk, etc).

    I believe we're protected against packeting sniffing, ARP poisoning, IP address spoofing, man in the middle etc by using SSL.

    Maybe I'm being paranoid, I just don't like it sitting there so accessible in plain text. That said, I presume that all web applications, including internet banking etc, suffer from this problem?

    Monday, June 14, 2010 8:15 PM
  • User435801899 posted

    While we're on the subject, I'm skeptical about the value of rotating session keys - I don't think the overhead (complexity of session management) justifies the security benefit (which I think is none).

    I think the benefit is zilch for two reasons - 

    * Whatever mechanism the evil hacker used to acquire the session key originally can be used again to acquire it post-rotation

    * Alternatively, hacked correctly, the server may end up mindlessly distributing the new session key to the hacker instead of the victim

    For these reasons I've decided not to implement this in our system. Interested in your feedback.

    -Brendan

    Monday, June 14, 2010 8:35 PM
  • User-861155893 posted

    if they have access to your box directly session cookies are the least of your issues. And SSL does not protect you against MITM... consider:

    jane visits banking site but unbeknown man in middle captures banking SSL cert. MITM sends fake SSL to jane which causes popup about unsecured SSL (only drawback). She accepts, janes 'encrypted' traffic is sent to MITM who can then decode, and his 'ware' then encrypts and sends using original real ssl cert...

    are your arp caches hardened?... all your usb ports, ethernet ports, etc secured?? if not then you are not secure against spoofs. Your users educated on social engineering? password policies?... no system is secured unless it is unplugged.

    BUT. in any Sec Policy you have to balance productivity against security.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, June 14, 2010 8:37 PM
  • User-861155893 posted

    What application is this? Banking?

    In my opinion:

    If the user is sending sensitive information you MUST take reasonable steps to safeguard them. How would you like it if by visiting your application and having your password (most users use same pwd for a lot of stuff) found?


    Monday, June 14, 2010 8:44 PM
  • User435801899 posted

    My understanding of SSL certificates is that the cert the MITM sends to the victim would be unable to be verified? ie. a warning would come up (which hopefully the user would pay attention to). Perhaps I've misunderstood.

    You're right though - security is a degree, not a boolean value.


    Monday, June 14, 2010 8:44 PM
  • User-861155893 posted

    yeah i identified that drawback ;)

    "...jane which causes popup about unsecured SSL (only drawback). She accepts,..."

    but 'dumb' users are ingenious at finding ways to break things ;)

    Monday, June 14, 2010 8:48 PM
  • User435801899 posted

    Not a banking application, but large amounts of confidential and business critical data. Most users are relatively powerful (necessarily so) so a captured session key could do a lot of harm. More to the business data, rather than the end users.

    Of course I'm concerned about security and confidentiality, that's the whole point of this thread. I'm interested in feedback on my criticisms of session key rotation.

    Monday, June 14, 2010 8:49 PM
  • User435801899 posted

    Lol true

    *swallows potion of +3 to reading comprehension*

    Monday, June 14, 2010 8:52 PM
  • User-861155893 posted

    I think really if you want to secure then you have to employ a variety of techniques (layered sec)...

    it is a tough one though... the higher the value of the data the more attention you must pay. unfortunately you build up the walls and if the incentive is high enough someone will try bring it all crashing down (and most likely will succeed eventually)

    A good discussion on session stuff is in php man pages

    http://www.php.net/manual/en/session.security.php

    great topic though... any MVPs have any advice?

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, June 14, 2010 9:05 PM