SitePoint Sponsor

User Tag List

Results 1 to 18 of 18
  1. #1
    3MTA3
    Join Date
    Jul 2003
    Location
    Florida
    Posts
    1,016
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    how unique is session_id()?

    I've been following a book on setting up ecommerce applications and they appear to use the session_id() to track items to customers' orders. Is there ever a chance that the session_id() could ever be duplicated down the road, which would cause invalid items being linked to users? Am I just paranoid?

  2. #2
    SitePoint Addict
    Join Date
    Feb 2004
    Location
    belfast
    Posts
    386
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by devised
    I've been following a book on setting up ecommerce applications and they appear to use the session_id() to track items to customers' orders. Is there ever a chance that the session_id() could ever be duplicated down the road, which would cause invalid items being linked to users? Am I just paranoid?
    Should be unique ... but why not combine it with a time stamp and md5 it? That should cover all possibilities?

  3. #3
    3MTA3
    Join Date
    Jul 2003
    Location
    Florida
    Posts
    1,016
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    That's kinda what I was thinking. I was wondering if the session_id() is generated based on the time stamp. Anyone know?

    It's hard for me to research online right now (have my laptop hooked up to my cell phone so it's super slow speed internet).

  4. #4
    SitePoint Guru
    Join Date
    Jun 2004
    Location
    Finland
    Posts
    703
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It'd be wrong to say that it's impossible, so let's just say that it's very, very unlikely.

    Quote Originally Posted by php.net/session
    Sessions and security

    External links: Session fixation (http://www.acros.si/papers/session_fixation.pdf)

    The session module cannot guarantee that the information you store in a session is only viewed by the user who created the session. You need to take additional measures to actively protect the integrity of the session, depending on the value associated with it.

    Assess the importance of the data carried by your sessions and deploy additional protections -- this usually comes at a price, reduced convenience for the user. For example, if you want to protect users from simple social engineering tactics, you need to enable session.use_only_cookies. In that case, cookies must be enabled unconditionally on the user side, or sessions will not work.

    There are several ways to leak an existing session id to third parties. A leaked session id enables the third party to access all resources which are associated with a specific id. First, URLs carrying session ids. If you link to an external site, the URL including the session id might be stored in the external site's referrer logs. Second, a more active attacker might listen to your network traffic. If it is not encrypted, session ids will flow in plain text over the network. The solution here is to implement SSL on your server and make it mandatory for users.
    However, I don't trust PHP's built-in session system. I know I'm being a little paranoid but I usually create a system of my own, including custom session ids. Storing the data into a database is definitely the way to go. IP & User-Agent checking is also a good idea, although it might make some dynamic-ip'ers unhappy.

    Quote Originally Posted by devised
    I was wondering if the session_id() is generated based on the time stamp.
    It should be, as it ensures the uniqueness. Now I don't know if this is true at all but I think that it's created like the '$better_token' in here.

  5. #5
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Proberly as unique as you and me, as individuals yes? Don't worry about it, really. What is the probibility of there being an exact copy of my DNA in another human being?

    Exactly...

  6. #6
    throw me a bone ... now bonefry's Avatar
    Join Date
    Nov 2004
    Location
    Romania
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Actually it's a 0% probability simply because PHP when it generates that ID it checks to see if it doesn't allready have an active session with that ID.

    Quote Originally Posted by Sorccu
    However, I don't trust PHP's built-in session system. I know I'm being a little paranoid but I usually create a system of my own, including custom session ids.
    I keep the session in the DB myself, but to generate your own custom ID, well.... that's really paranoid. Stop now before you hurt yourself

  7. #7
    SitePoint Guru
    Join Date
    Jun 2004
    Location
    Finland
    Posts
    703
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Duh. I always fail to make my posts tell what I really mean
    Quote Originally Posted by bonefry
    Actually it's a 0% probability simply because PHP when it generates that ID it checks to see if it doesn't allready have an active session with that ID.
    But what if two sessions are created at the exactly same time? I know it's highly unlikely but wouldn't it be possible then?
    Quote Originally Posted by bonefry
    I keep the session in the DB myself, but to generate your own custom ID, well.... that's really paranoid. Stop now before you hurt yourself
    Hehe, maybe

  8. #8
    011110010110000101111001 jabird's Avatar
    Join Date
    Aug 2004
    Location
    U.S.
    Posts
    593
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Sorccu
    Duh. I always fail to make my posts tell what I really mean

    But what if two sessions are created at the exactly same time? I know it's highly unlikely but wouldn't it be possible then?

    Hehe, maybe
    geez, are you running a top secret military site or something? :P
    ~Jabird
    Jabird.com
    If I were binary... I'd be all 1's for you.
    BBCode trouble?

  9. #9
    SitePoint Addict DA Master's Avatar
    Join Date
    Apr 2004
    Location
    /etc/php.ini
    Posts
    398
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well your session id is 32 characters long, and it has a-z and 0-9, what are the chances of it been replicated and if so, I would ask why you are keeping session id's for that length of time.

  10. #10
    SitePoint Guru mwolfe's Avatar
    Join Date
    Mar 2005
    Posts
    912
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    2 identical session id's at the same time?? computers can't do 2 things at the same time.. 1 then the other.. If you have multiple processors/multiple cores.. i think only 1 will be dedicated to a given process, so still, only one can generate session id's.. Sorry man, but i'm not seeing how 2 session id's at the same time could happen.. And then there is what, 1x10^-35 chance of two session id's having the same id (out of 2). therefore if you had a million sessions at the same time there is still only 1x10^-29 chance. (not actually workign the math out, just guessing.. )

  11. #11
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Brooklyn, NY
    Posts
    359
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by devised
    I've been following a book on setting up ecommerce applications and they appear to use the session_id() to track items to customers' orders.
    This is how sessions work, assuming you don't actually mean session_id() the function. Session data is associated with a unique identifier also known as the session identifier. PHP's is called PHPSESSID by default.

    Quote Originally Posted by devised
    Is there ever a chance that the session_id() could ever be duplicated down the road, which would cause invalid items being linked to users?
    Regardless of all other factors, remember that the session identifier PHP generates is a 128 bit number, which means there are more than 3.4 * 10^38 possibilities. Even Yahoo, the busiest site on the web, only gets about 5 billion hits a day, which is 5 * 10^9. If they store a session for every single hit for the next billion years, that would use up only 1.8 * 10^21.

    Quote Originally Posted by ronanmagee
    Should be unique ... but why not combine it with a time stamp and md5 it? That should cover all possibilities?
    Think about what you're saying for a minute. An MD5 is a 128 bit number. That's exactly what a session identifier is already. You're not adding any additional permutations.

    The only gain you can hope from further processing like this is to add more entropy (randomness). But, time is anything but random, so you're not even doing that. This is a step in the wrong direction.

    Quote Originally Posted by devised
    I was wondering if the session_id() is generated based on the time stamp. Anyone know?
    No, because that would be foolish.

    Quote Originally Posted by Sorccu
    However, I don't trust PHP's built-in session system. I know I'm being a little paranoid but I usually create a system of my own, including custom session ids.
    That's not being paranoid - that's being foolish. It is very unlikely that you can generate a better session identifier than PHP's native session mechanism. If you really think you can, you should share your research with the PHP development team, so that PHP's native session mechanism can be improved. You'll have to defend your methods, though.

    Quote Originally Posted by Sorccu
    But what if two sessions are created at the exactly same time?
    I think you're greatly underestimating the PHP development team. Do you really think you're going to come up with a situation that hasn't been considered with just a few seconds of thought? This is something that has been developed and refined over years and is being used by millions of sites around the world. Have a little more faith. :-)
    Chris Shiflett
    http://shiflett.org/

  12. #12
    SitePoint Guru mwolfe's Avatar
    Join Date
    Mar 2005
    Posts
    912
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for clearing that up... I had a feeling php's session id creation was a bit more thoroughly thought out then some previous posts suggested.

  13. #13
    Don't eat yellow snow spaceman's Avatar
    Join Date
    Mar 2001
    Location
    Melbourne, Australia
    Posts
    1,039
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Unhappy

    Quote Originally Posted by bonefry
    Actually it's a 0% probability simply because PHP when it generates that ID it checks to see if it doesn't allready have an active session with that ID.
    I totally hear and agree with what you and all other wise soles in this thread are saying, BUT

    Under what circumstance(s) is it possible that the same session ID is being given to 2 or more completely unrelated visitors to a site?

    Why do I ask? Because it happens. I don't know why it happens, but it does. V. occasionally.

    It happened 4 months ago on my wife's e-commerce site. She suddenly started getting complaints from customers that they were seeing other people's name and address details and products (and more - but not cc details!) in their shopping carts. It completely baffled me. The explanation - but not solution - was that, somehow, a uniquely generated session ID was being given to a second visitor to the site. After about 6 complaints over about 24-48 hours, the problem stopped and hasn't re-occured (before or since), and I don't believe that anything I did in that period (which wasn't very much apart from storing session ids in their own dir instead of /tmp) was responsible for fixing the problem.

    And now it's happening again on another site of ours powered by Zen Cart (note: my wife's site I wrote myself from scratch, nothing to do with Zen Cart). Same complaints from customers.

    So I don't doubt for a second the impossibility of duplicate session IDs being randomly assigned to two different visitors to a site. I rule this out 100%. But what I do think is happening is that, under some rare set of conditions (which I'd love to understand and nail) a session ID is given to someone else.

    Perhaps a server (apache? php?) config problem? Permissions on the /tmp dir?

    Note that on my wife's site sessions are NOT managed or recorded in a mysql db, whereas on the Zen Cart site they are. Also note that both sites use php to decide what the unique session ID should be - neither attempts to do customised session id creation (why would you!).

    Help! Can anyone think of anything? Here's hoping!
    Web Design Perth Melbourne .:. Itomic Business Website Solutions
    Drupal Experts .:. Drupalise

  14. #14
    SitePoint Addict DA Master's Avatar
    Join Date
    Apr 2004
    Location
    /etc/php.ini
    Posts
    398
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    So you are open to session fixation but you didnt know?

  15. #15
    SitePoint Guru
    Join Date
    Jun 2004
    Location
    Finland
    Posts
    703
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by shiflett
    It is very unlikely that you can generate a better session identifier than PHP's native session mechanism.
    I know it's really not more secure if targeted, but it gives protection against possible randoms, no matter how rare they be.
    Quote Originally Posted by shiflett
    This is something that has been developed and refined over years and is being used by millions of sites around the world. Have a little more faith. :-)
    It being used by millions of sites around the world doesn't really make it more secure, but yes, I see your point

  16. #16
    SitePoint Guru
    Join Date
    Jun 2004
    Location
    Finland
    Posts
    703
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by spaceman
    I totally hear and agree with what you and all other wise soles in this thread are saying, BUT

    Under what circumstance(s) is it possible that the same session ID is being given to 2 or more completely unrelated visitors to a site?

    Why do I ask? Because it happens. I don't know why it happens, but it does. V. occasionally.

    It happened 4 months ago on my wife's e-commerce site. She suddenly started getting complaints from customers that they were seeing other people's name and address details and products (and more - but not cc details!) in their shopping carts. It completely baffled me. The explanation - but not solution - was that, somehow, a uniquely generated session ID was being given to a second visitor to the site. After about 6 complaints over about 24-48 hours, the problem stopped and hasn't re-occured (before or since), and I don't believe that anything I did in that period (which wasn't very much apart from storing session ids in their own dir instead of /tmp) was responsible for fixing the problem.

    And now it's happening again on another site of ours powered by Zen Cart (note: my wife's site I wrote myself from scratch, nothing to do with Zen Cart). Same complaints from customers.

    So I don't doubt for a second the impossibility of duplicate session IDs being randomly assigned to two different visitors to a site. I rule this out 100%. But what I do think is happening is that, under some rare set of conditions (which I'd love to understand and nail) a session ID is given to someone else.

    Perhaps a server (apache? php?) config problem? Permissions on the /tmp dir?

    Note that on my wife's site sessions are NOT managed or recorded in a mysql db, whereas on the Zen Cart site they are. Also note that both sites use php to decide what the unique session ID should be - neither attempts to do customised session id creation (why would you!).

    Help! Can anyone think of anything? Here's hoping!
    Read this pdf and Sessions and Security here.

  17. #17
    Programming Team silver trophybronze trophy
    Mittineague's Avatar
    Join Date
    Jul 2005
    Location
    West Springfield, Massachusetts
    Posts
    17,290
    Mentioned
    198 Post(s)
    Tagged
    3 Thread(s)

    number of possible session id-s

    The math for determining the number of possible variations is
    # of possible values to the # of elements power.
    So a-z, 0-9 - 36 possible values, with 35 positions is:
    36^35 possible different session id-s
    That's 39,552 10^50 so if the world's population is currently 6,446,131,400
    that means that Every person in the world would have to be logged on
    45,844 10^44 times. Not very likely, I think you'll agree

    If the same session id is being assigned to different users I would look for errors in script logic, variable naming conlflicts, or table locking, etc. Maybe a thread problem? And most definately take steps to prevent fixation attacks.

  18. #18
    Don't eat yellow snow spaceman's Avatar
    Join Date
    Mar 2001
    Location
    Melbourne, Australia
    Posts
    1,039
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Sorccu
    Read this pdf and Sessions and Security here.
    Nice. Thanks.

    The section in that pdf titled 'Restricting the session ID usage' should do the trick, eg. the advice to bind the session id to the browser's network address (as seen by the server).

    That said - and whilst I like the 'solutions' and will implement them - my feeling is still that what I've observed is a failure in the way sessions are generated/allocated by standard techniques as opposed to a malicious attack per se.
    Web Design Perth Melbourne .:. Itomic Business Website Solutions
    Drupal Experts .:. Drupalise


Bookmarks

Posting Permissions

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