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
