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 4 of 4
  1. #1
    Codeasaurus Rex
    Join Date
    Jun 2008
    Location
    Redmond, WA
    Posts
    659
    Thanks
    31
    Thanked 100 Times in 94 Posts

    Hacking into session variables possible?

    Geniuses of the PHP Department, I beseech thee:

    A website that I'm developing hinges its security on storing session variables with data that cannot be tampered with. If a user is able to hack into it and change some values around it wouldn't be good news in my department.

    After some unsuccessful Google searches I'm wondering if any of you know of a way to accomplish this and, if so, how to prevent it.

    FYI: My entire site requires a 128-bit SSL connection before it will execute any page loads, if that affects anything.

    Thanks!
    Unless otherwise stated, any code posted is most likely untested and may contain syntax errors.
    My posts, comments, code, and suggestions reflect only my personal views.
    Web Portfolio and Code Snippets: http://shanechism.com

  • #2
    bdl
    bdl is offline
    Regular Coder
    Join Date
    Apr 2007
    Location
    Camarillo, CA US
    Posts
    590
    Thanks
    4
    Thanked 83 Times in 82 Posts
    If you're on a shared server, session data can be easily read. I've not thought about it or tried it, but since the session files are just that, files, and are typically stored in a user-accessible area such as "/tmp" for example that anyone can write to, I suppose it would be trivial to alter the data. The session file gets written to the server somewhere (which can be found through a PHP mechanism regardless of where they hide it), and is writable by the HTTPD process. It has to be in order to exist.

    If you're not on a shared server, I wouldn't be concerned.

    Unfortunately the SSL connection will only secure the state between the server and the client.

    Regardless, you can use a database storage mechanism rather than a flat file for more security.

  • #3
    Codeasaurus Rex
    Join Date
    Jun 2008
    Location
    Redmond, WA
    Posts
    659
    Thanks
    31
    Thanked 100 Times in 94 Posts
    First of all, thanks for the response !

    Right, I've got that part - my concern, I suppose, is the user somehow editing their session data without access to the server. You bring up a good point in that I suppose they could accomplish their goal with directory traversal - but then again if they have access to that I suppose I have bigger things to worry about!

    My current security is essentially three $_SESSION stored variables for the user: Their Unique User ID, their username, and their hashed password. Then, on every page requiring authentication, I use the username and password to re-load their Unique User ID from the database, and of course display appropriate errors if there's a problem.

    Is there a better method you can see for account security on the user side? The only ones I'm aware of are $_SESSION and $_COOKIE, and cookies get themselves into all sorts of trouble.
    Unless otherwise stated, any code posted is most likely untested and may contain syntax errors.
    My posts, comments, code, and suggestions reflect only my personal views.
    Web Portfolio and Code Snippets: http://shanechism.com

  • #4
    bdl
    bdl is offline
    Regular Coder
    Join Date
    Apr 2007
    Location
    Camarillo, CA US
    Posts
    590
    Thanks
    4
    Thanked 83 Times in 82 Posts
    Ah. I would never recommend storing the username and password, hashed or not. A good alternate is to have a separate lookup table that only stores login data, e.g. userid value along with a random token which of course would be a hashed string of some sort. The session stores the userid and/or token, and on each page request these values are matched against the lookup table. To help avoid spoofing, you should consider updating the token values per-page-request, and issue a session_regenerate_id() call for a fresh session id.

    Use non-specific names for whatever values you choose.

    Additionally, you can store the time the user logged in and/or the time of the last request, etc. and perform some housecleaning task based on that. Storing and comparing IP addresses is a waste of time.


  •  

    Posting Permissions

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