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 5 of 5
  1. #1
    Regular Coder bacterozoid's Avatar
    Join Date
    Jun 2002
    Location
    USA
    Posts
    490
    Thanks
    24
    Thanked 35 Times in 35 Posts

    Expiring database sessions on browser close

    First of all, I know this is not possible. I am also not using any of the built-in session functions in PHP; I'm using setcookie() and a database to store session data.

    Second, if I set $expire=0 in setcookie(), this will cause the browser to discard the cookie when it is closed. Visiting my site after the fact then means that no cookie will be sent to the server and thus you would not be logged in.

    In order to make that work in the database, I have to set the expiration to some arbitrary time in the future. After all, the user could have their browser open for one hour or one day or one week. Let's say I go all out and set the session in the database to expire after one year for good measure. Now the session is good for at least that long, but is their any concern for someone might somehow steal the cookie from some computer and then just re-use it?

    Or maybe it doesn't matter at all. After all, if someone can get to the cookie on your computer then you probably have other problems, right?

    Just looking for some clarification on whether or not this is the correct and secure way to do things. Thanks!

  • #2
    Senior Coder
    Join Date
    Apr 2011
    Location
    London, England
    Posts
    2,120
    Thanks
    15
    Thanked 354 Times in 353 Posts
    Why are you not using built-in functions? Sessions and security is a very large topic and you will need to read about it in some depth, particularly if you are attempting to build your own custom-system.
    "I'm here to save your life. But if I'm going to do that, I'll need total uninanonynymity." Me Myself & Irene.
    Validate your HTML and CSS

  • #3
    Senior Coder
    Join Date
    Feb 2011
    Location
    Your Monitor
    Posts
    4,295
    Thanks
    57
    Thanked 524 Times in 511 Posts
    Blog Entries
    5
    Quote Originally Posted by AndrewGSW View Post
    Sessions and security is a very large topic
    But it only has one page dedicated to it consisting of three paragraphs

    Sessions will always be hackable somehow.

    Sessions work by sending the session id with every http request. Either in the request headers by posting a cookie or via the url. Anyone who is monitoring your TCP traffic can get your session identifier and other information (such as expiry) and use it.

    You could implement an IP check.. again those can be spoofed.

    You could use SSL.. not much good if the users system is infected with a trojan (plus SSL is crackable).

    You can use random keys in the url but the user only needs to open a link in another tab.. so you implement rolling keys.. that becomes even more complex and to accomodate it you have to have several keys available and thus the attacker could borrow one of those..

    The problem with sessions is that they depend entirely on the users browser to work. With that being the case, you will never come up with a 100% solid way of protecting them and that is why php.net have such a short article about it on the page you link to because in reality, you cannot completely safeguard against hijacking.

    As for why someone would want to implement their own sessions system, quite simple really, phps native session handler has garbage collection and can be a pain when sessions timeout after 24 minutes (this can be a pain to change). Implementing session storage in a database means you can ignore the garbage collector and keep those sessions available until a time when you wish to delete them. Thats the first reason I can think of..
    See my new CodingForums Blog: http://www.codingforums.com/blogs/tangoforce/

    Many useful explanations and tips including: Cannot modify headers - already sent, The IE if (isset($_POST['submit'])) bug explained, unexpected T_CONSTANT_ENCAPSED_STRING, debugging tips and much more!

  • Users who have thanked tangoforce for this post:

    bacterozoid (03-27-2013)

  • #4
    Regular Coder bacterozoid's Avatar
    Join Date
    Jun 2002
    Location
    USA
    Posts
    490
    Thanks
    24
    Thanked 35 Times in 35 Posts
    Thanks, Tango for the response. Your reasoning for implementing custom session handling is basically on track with mine. I know I can set up a session handler and use a database and all that jazz, but it's so much easier to use setcookie() directly and handle the database on my own. If I was new to this I would stick to the basics but I've been doing this for years.

    After re-reading my post I realize I'm actually doing a couple things wrong which I'll need to address, but what I was looking for was confirmation on whether or not it's reasonable to assume that worrying about a stolen cookie/session (when using SSL) is worth it, because if a computer is compromised enough to hand out that information, then there are already worse problems.

  • #5
    Senior Coder
    Join Date
    Feb 2011
    Location
    Your Monitor
    Posts
    4,295
    Thanks
    57
    Thanked 524 Times in 511 Posts
    Blog Entries
    5
    Worrying abou stolen cookies .. well its something we all see with varying levels of importance.

    I personally don't worry about it too much because I can implement all sorts of things but at the end of the day, http traffic can be sniffed, SSL can be cracked and trojans can pinch all sorts of information.

    The best thing you can do is to have a secondary password or pin number and randomly redirect the user to a confirmation page asking for the xth digits from it (eg 1st and 3rd). This means you never transmit the whole thing at the same time but does of course carry another risk that should someone get their hands on your tables they may have access to the whole thing (you could of course store each digit as a hash though but even then a hacker could generate hashes for each letter of the alphabet and then workout what each hash in your table is).

    SSL is really the best way forward as you'd need to be a pretty top end hacker to crack it and steal http traffic but its not impossible. It will however hold off most script kiddies who are playing with tcp packet sniffers.
    See my new CodingForums Blog: http://www.codingforums.com/blogs/tangoforce/

    Many useful explanations and tips including: Cannot modify headers - already sent, The IE if (isset($_POST['submit'])) bug explained, unexpected T_CONSTANT_ENCAPSED_STRING, debugging tips and much more!


  •  

    Posting Permissions

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