RE: [PHP] Session Question

You should be able to use $_SESSION with register_globals on. <citation from manual> " If you want your script to work regardless of register_globals, you need to use the $_SESSION array. All $_SESSION entries are automatically registered. If your script uses session_register(), it will not work in environments where register_globals is disabled. " -----Oorspronkelijk bericht----- Van: Pushpinder Singh Garcha [mailto:pgarcha@adelphia.net] Verzonden: Wednesday, May 28, 2003 6:18 PM Aan: Ernest E Vogelsinger CC: php-general@lists.php.net Onderwerp: Re: [PHP] 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 > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php