SitePoint Sponsor

User Tag List

Results 1 to 6 of 6
  1. #1
    SitePoint Member
    Join Date
    Oct 2006
    Posts
    22
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Session Security

    Is it enough these days that when the user login give that user a session with his/hers userid?

    And then on every page check the session userid? I have seen some applications with a "sessionkey" field in the database and then on every page it checks against the database if that key exists.

    But to query the database on every page will be very intensive for the database right? Whats the most secure way to go and still keep performance?
    Last edited by tehKing; Nov 23, 2006 at 06:21.

  2. #2
    SitePoint Zealot
    Join Date
    Apr 2006
    Posts
    158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    why not using session variables?

  3. #3
    SitePoint Member
    Join Date
    Oct 2006
    Posts
    22
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    jito, the question here was not really why or why not.

  4. #4
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by tehKing
    But to query the database on every page will be very intensive for the database right? Whats the most secure way to go and still keep performance?
    I don't think that's much of a problem actually. If you need to identify the user, chances are that you are going to do a lot of database access anyway, so a single select isn't a performance problem. The question is if it adds any value. Checking the database for a session-id basically means that you don't trust the session handler, and I can't see why you shouldn't be able to do that. So I think it's redundant.

    To avoid session fixation, you should always generate session-id when peoples access increase (Eg. when they go from anonymous to logged in). You can simply call the function session_regenerate_id for that. This is a whole other issue, but one people often miss.

    Chris Shiflett has a bunch of good articles on security:
    http://shiflett.org/articles

  5. #5
    SitePoint Zealot logitron's Avatar
    Join Date
    Feb 2006
    Posts
    144
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have faced the same question myself concerning using sessions and how exactly to maintain security. There might be better ways of doing it, but I basically store the users ID and encrypted password into session variables when the user logs into the site. Then, with each page, I check the database against that ID/encrypted password combo for a match.

    I understand not wanting to query the database so much, but heck, that's the only thing that truly knows if the user IS who he/she claims to be! :P
    Patrick Smith
    PHP Programmer

  6. #6
    SitePoint Wizard silver trophy
    Join Date
    Mar 2006
    Posts
    6,132
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    sessions are a database in a sense, although by default they are usually plain text files in a directory that everyone on a shared webserver can read/write to.

    you could configure php to store your sessions in a seperate directory, or a database.
    if your host has php running as your own user(for example, suPHP), then creating a session directory which only your user can access is a decent solution. if php does not run as your own user, then other people on the same shared server may be able to read your php files anyway(open_basedir may stop that), and could find your database password and anything else valuable.

    so really, i think this only serves as an additional layer of protection against other users on the same shared webserver. so if you want to build a barrier against this, you should also be considering how to protect against someone who has at least partial filesystem access to your machine...not an easy task.

    if you cannot trust the data in your sessions, then yes revalidating against the db is a decent idea. but if you cant trust the sessions, maybe you should be asking if you can trust the database too.

    in my opinion, storing session files in your own directory, or in a database is a must on a shared server.


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
  •