Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 3 of 3

Thread: Secure sessions

  1. #1
    Senior Coder Mhtml's Avatar
    Join Date
    Jun 2002
    Location
    Sydney, Australia
    Posts
    3,531
    Thanks
    0
    Thanked 1 Time in 1 Post

    Secure sessions

    I'm making a CMS for a computer hardware retail website and I'm trying to implement a shopping cart..

    This cart works like most carts you see on the web, you can browse the range of goods adding a quantity of an item as you wish and modifying this on the main shopping cart page before going to the checkout.

    Now, instead of cookies I was going to use sessions to keep track of the shopping cart of the user while they shop. This is where my problem comes up, what if someone edited their session id which I carry along as a querystring and got someone else's session id? They could mess with that users shopping cart and this would pose a problem..

    So, what I'm thinking of now is instead of using a session id I would make everyone signup and login to shop and just have a unique user id for the cart and that is pretty much secure but of course rather annoying ..

    So now I'm looking for a balance of security and ease for this ...

    So what I've come up with now, is sort of a balance... For users that have cookies enabled I'd use a session and store it in a cookie with their browser .. for those who don't have cookies enabled they would have to signup and login to shop..

    Is there a better way than my last idea though?

    [edit:] You would have to login everytime you submitted a change to your cart BTW seeing as cookies wouldn't be available ... (hence annoying)
    Last edited by Mhtml; 01-12-2004 at 03:30 PM.
    Omnis mico antequam dominus Spookster!

  • #2
    Senior Coder
    Join Date
    Jun 2002
    Location
    frankfurt, german banana republic
    Posts
    1,848
    Thanks
    0
    Thanked 0 Times in 0 Posts
    So what I've come up with now, is sort of a balance... For users that have cookies enabled I'd use a session and store it in a cookie with their browser .. for those who don't have cookies enabled they would have to signup and login to shop.
    What makes you so sure that users won't edit the session id in the cookie file? It's client data, per se editable by the user. Just having it not in the URL prevents for leakage of the session id itself, but does not protect against editing.

    Further, have you really experienced that you accidentally overtook another session by manipulating the session id? We're talking of randomly generated hash strings here. The chance that sth. like this could happen should fairly minimal, of course relative to the number of concurrent users. But I'd say that with 100 active sessions the chance of capturing another session by switching some chars in the id is smaller than typing a password in a login form and guessing the correct one. Anyway, did you manage did "steal" a session this way?

    You are of course very right to worry about the security of a session-based web application. The first thing to take care of is that the session id itself is not leaked to the outside, through referers, bookmarks, sent files. Requiring cookies actually helps increase security in this case, contrary to popular belief. But with a cookie-based solution you have to be wary of potential XSS attacks, if your users have the possibility to post bbCode somewhere on your site (though that seems unlikely for a hardware retailer).

    Thinking about the session itself, you can try to tie more info about the client in the session. You could store the IP address in the session and compare that on subsequent requests, but because some ISPs assign IPs on a very short interval, this measure might be useless. You could save the user agent string and compare that, but then, how many users, do use IE6, so nothing won here.

    So what to do? The OWASP guide contains some great info about application security, and has a chapter devoted to session management. You find a lot of proven concepts there, and I don't have to write them all into this tiny textarea.
    But look at "page tokens", they might be what you look after.

    Generally, use reauthentication before actually buying something or viewing personal info. Let sessions expire, and instantiate completely new session each time a login is done (e.g. don't reuse passed session ids, AKA "session fixation"). Destroy sessions after a user logs out.

    And BTW, you said it almost yourself, and I have to agree: The login procedure for the no-cookie users won't get accepted by your customer. No one will want to use this shop if it behaves so annoyingly different compared to other sites.
    Last edited by mordred; 01-12-2004 at 07:24 PM.
    De gustibus non est disputandum.

  • #3
    Senior Coder Mhtml's Avatar
    Join Date
    Jun 2002
    Location
    Sydney, Australia
    Posts
    3,531
    Thanks
    0
    Thanked 1 Time in 1 Post
    Wow, thanks for the reply ... I know the chances of guessing a session are incredibly minimal but I couldn't help but worry...

    Reauthentication is a good idea, and tying in more info is another avenue also ... I'll have a look at that website in a little while..

    Thanks again ..
    Omnis mico antequam dominus Spookster!


  •  

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •