Re: Session Question

Hello Ernest, SInce register_globals() is ON on my server, I need to be able to figure out a way to ensure session security. Another question I had was that, with register_globals() ON can I still use the $_SESSION to set my variables ? I want to avoid recoding the entire application, so I want to see what can be done to enhance security with the current setup. Does the super-global array approach i.e. $_SESSION work, irrespective of the fact that REGISTER_GLOBALS is ON / OFF ? If I start setting session variables in the $_SESSION array from now on, will it improve the security of the session. I am a newbie in PHP session handling and am sorry if any of the above questions sound extremely lame. Thanks in advance, --Pushpinder On Wednesday, May 21, 2003, at 04:34 PM, Ernest E Vogelsinger wrote:

At 21:51 21.05.2003, Pushpinder Singh Garcha said: --------------------[snip]--------------------

register_globals is ON on my site.

You should really rethink this - have a look at

    http://www.php.net/manual/en/security.registerglobals.php
    http://www.php.net/manual/en/ref.session.php section "Sessions and

Security" register_globals=on simply enables anyone injecting globals to your site:

    http://www.yoursite.com/myscript.php?valid_user=sam+spade

To keep sessions secure, one might consider these steps: (1) Filesystem security: session.save_path points to a directoy owned and readable by the webserver user only:

    session.save_path=/tmp/php
    chown apache:apache /tmp/php
    chmod 700 /tmp/php

(2) If security issues are high you may attempt to make sure that the session identifier - be it via cookie or via URL parameter - gets additional confirmation. I once used this approach: I am transmitting a random cookie (random name, random value) to the browser, making a note (in $_SESSION) of the cookie name and its value. When the session gets revisited check for the existence and the value of this cookie. If the values match construct another random cookie, having another name and another value (also sending header information to delete the old cookie). If the cookie doesn't match don't discard the session but merely redirect the browser to another URL (usually a login page), clearing the session ID if it was received it as cookie. This has a drawback - clients are forced to accept cookies, or the system wouldn't work at all. Thus you can only implement it where security is at risk, and where acceptance of the additional cookie can be enforced (extranet applications, for example). (3) As a last resort one can remember the client IP that must match for the same session. This is not secure at all, and it doesn't work with some AOL connections where client IPs change at will (by AOL using random proxies for every INet connection). You can however automatically rule out that method if the client IP stems from the AOL-assigned range. Keeping a very good eye on session security, sessions are the only thing where you can keep login data and access rights, just like you're doing it. I would only urge you NOT to use session_register() and session_is_registered(), but to use the $_SESSION[] superglobal to be absolutely sure you're using only data you yourself have put there, and not injected data. --

O     Ernest E. Vogelsinger

(\) ICQ #13394035 ^ http://www.vogelsinger.at/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php