Re: [PHP] Session contamination?
Yes, Chuck is correct here. The security issue I raised has to do with multiple users on the same shared server, which is how some hosting companies manage their clients. Each user may have a different home directory and has separation from other users, however, usually the same /tmp directory is used to store all the session cookies for all the users on the server. By running a simple script in your area you can read all the sessions managed by the server including sessions generated by other users. By moving the session cookies to a directory within your own user area it may make them more difficult to find, but it does not guarantee security as Chuck points out. This is discussed at [http://php.net/manual/en/ ref.session.php] as pointed out by Jochem. - Ben On Apr 20, 2006, at 7:22 PM, Richard Lynch wrote: On Thu, April 20, 2006 1:46 pm, Ben Liu wrote: After a bit more research, I think I understand why Jochem recommends use of session_save_path() rather than just naming each session differently. The former method provides more security as you can set the location where session cookies are stored. This will help prevent an attacker from gaining access to session information and then using it to gain inappropriate access to the application the session was created for or even other applications running on the same shared server. Anyway, I think that's why. ::Possible False Sense Of Security Alert:: If a Bad Guy can read the session data, moving it to a different directory is probably not going to help, really... Unless you are running with different Usernames for each client on your shared server, using FastCGI + suexec or some similar method, the cookie files are STILL just as readable by the same Bad Guys, using the same methods. They just have to change their to: ?php $path = /other/path/to/other/cookies;? before they start their damage. There may well be other GREAT reasons for using a different save path, or a different path for the Cookie, or session_name over each other, but I don't think Security is the reason behind any of the choices. I'd personally use ini_set as the last choice because it's remotely possible that the setting can't be changed from within a script, as a few are like that -- Or, worse, that they can be changed today, but in, say PHP 6 or PHP 7, they won't be for some obscure reason we cannot predict today. session_name() seems less likely to just disappear completely as a feature than a minor change to a php.ini setting and where it is allowed. But that's just my paranoid logic. :-) -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Session contamination?
Ach, correction: Chuck is correct here. = *Richard* is correct here. No morning coffee yet, sorry. - Ben On Apr 20, 2006, at 7:22 PM, Richard Lynch wrote: On Thu, April 20, 2006 1:46 pm, Ben Liu wrote: After a bit more research, I think I understand why Jochem recommends use of session_save_path() rather than just naming each session differently. The former method provides more security as you can set the location where session cookies are stored. This will help prevent an attacker from gaining access to session information and then using it to gain inappropriate access to the application the session was created for or even other applications running on the same shared server. Anyway, I think that's why. ::Possible False Sense Of Security Alert:: If a Bad Guy can read the session data, moving it to a different directory is probably not going to help, really... Unless you are running with different Usernames for each client on your shared server, using FastCGI + suexec or some similar method, the cookie files are STILL just as readable by the same Bad Guys, using the same methods. They just have to change their to: ?php $path = /other/path/to/other/cookies;? before they start their damage. There may well be other GREAT reasons for using a different save path, or a different path for the Cookie, or session_name over each other, but I don't think Security is the reason behind any of the choices. I'd personally use ini_set as the last choice because it's remotely possible that the setting can't be changed from within a script, as a few are like that -- Or, worse, that they can be changed today, but in, say PHP 6 or PHP 7, they won't be for some obscure reason we cannot predict today. session_name() seems less likely to just disappear completely as a feature than a minor change to a php.ini setting and where it is allowed. But that's just my paranoid logic. :-) -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Session contamination?
On Fri, April 21, 2006 6:28 am, Ben Liu wrote: Yes, Chuck is correct here. The security issue I raised has to do with multiple users on the same shared server, which is how some hosting companies manage their clients. Each user may have a different home directory and has separation from other users, however, usually the same /tmp directory is used to store all the session cookies for all the users on the server. By running a simple script in your area you can read all the sessions managed by the server including sessions generated by other users. By moving the session cookies to a directory within your own user area it may make them more difficult to find, but it does not guarantee security as Chuck points out. This is discussed at [http://php.net/manual/en/ ref.session.php] as pointed out by Jochem. I wouldn't rely on the home directories and open_basedir as a real super big security fence... I believe that on some versions of PHP on some servers under some httpd.conf setting which seem perfectly reasonable, a symlink from a directory within open_basedir to a file you really shouldn't be able to read lets you in. Or, at least, I know I have used something like this to help people retrieve files for which they managed to lose access through sheer stupidity. The restrictions PHP can impose are, really, kind of just hacks to try to fix something that is basically way outside the realm and control of PHP in the first place. They're useful hacks, mind, and will stop the casual snoop. But it's not something to bet the bank on. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Session contamination?
Hello All, I'm using a single development server to host multiple client projects, many of which require session management. I've noticed that sometimes when I test these various web apps (which are simply in separate sub directories) I get session leakage where logging in and establishing a session on one app allows me access to (automatically logs me in) to other app(s) on the same server. Or sometimes a session variable will be set across all the apps, like $_SESSION['username']. Is this due to the fact that sessions are established between client browsers and servers, regardless of directory/sub directory? What is the best way to avoid/prevent this problem? Should I be using specific Session ID's or Session names? Thanks for any help, - Ben -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Session contamination?
On 20/04/06, Ben Liu [EMAIL PROTECTED] wrote: Hello All, I'm using a single development server to host multiple client projects, many of which require session management. I've noticed that sometimes when I test these various web apps (which are simply in separate sub directories) I get session leakage where logging in and establishing a session on one app allows me access to (automatically logs me in) to other app(s) on the same server. Or sometimes a session variable will be set across all the apps, like $_SESSION['username']. Is this due to the fact that sessions are established between client browsers and servers, regardless of directory/sub directory? Yes - that's the default behaviour, although if you set session.cookie_path separately for each app, they shouldn't share session cookies. You might also want to look at session.save_path which will allow each app to save their session files in a different location. -robin -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Session contamination?
Thanks for the response Robin, I'm reading up on session.cookie_path now. It seems that this would require creating separate php.ini files for each application. On 4/20/06, Robin Vickery [EMAIL PROTECTED] wrote: On 20/04/06, Ben Liu [EMAIL PROTECTED] wrote: Hello All, I'm using a single development server to host multiple client projects, many of which require session management. I've noticed that sometimes when I test these various web apps (which are simply in separate sub directories) I get session leakage where logging in and establishing a session on one app allows me access to (automatically logs me in) to other app(s) on the same server. Or sometimes a session variable will be set across all the apps, like $_SESSION['username']. Is this due to the fact that sessions are established between client browsers and servers, regardless of directory/sub directory? Yes - that's the default behaviour, although if you set session.cookie_path separately for each app, they shouldn't share session cookies. You might also want to look at session.save_path which will allow each app to save their session files in a different location. -robin -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Session contamination?
Hi Dave, Thanks, I think the method recommended by Robin using the function ini_set() would work, but somehow I think this could be done in simpler fashion by setting separate session names for each app, unless I am misunderstanding the use of session_name(). Trying this out now... - Ben On 4/20/06, Dave Goodchild [EMAIL PROTECTED] wrote: You can use ini_set to alter this value locally (until the script exits) in the script itself, which saves having to use a separate ini file if that is the only value you want to change. On 20/04/06, Ben Liu [EMAIL PROTECTED] wrote: Thanks for the response Robin, I'm reading up on session.cookie_path now. It seems that this would require creating separate php.ini files for each application. On 4/20/06, Robin Vickery [EMAIL PROTECTED] wrote: On 20/04/06, Ben Liu [EMAIL PROTECTED] wrote: Hello All, I'm using a single development server to host multiple client projects, many of which require session management. I've noticed that sometimes when I test these various web apps (which are simply in separate sub directories) I get session leakage where logging in and establishing a session on one app allows me access to (automatically logs me in) to other app(s) on the same server. Or sometimes a session variable will be set across all the apps, like $_SESSION['username']. Is this due to the fact that sessions are established between client browsers and servers, regardless of directory/sub directory? Yes - that's the default behaviour, although if you set session.cookie_path separately for each app, they shouldn't share session cookies. You might also want to look at session.save_path which will allow each app to save their session files in a different location. -robin -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- http://www.web-buddha.co.uk dynamic web programming from Reigate, Surrey UK look out for project karma, our new venture, coming soon! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Session contamination?
Ben Liu wrote:
Hi Dave,
Thanks, I think the method recommended by Robin using the function
ini_set() would work, but somehow I think this could be done in
simpler fashion by setting separate session names for each app, unless
I am misunderstanding the use of session_name(). Trying this out
now...
passing a different/unique value to session_name() should avoid inadvertent
contamination.
[http://php.net/manual/en/function.session-name.php]
Robin's second suggestion of setting the save path can be done with
session_save_path() as well as via ini_set().
[http://php.net/manual/en/function.session-save-path.php]
Robin's first suggestion is the one I would implement first, you can set the
[url]path for which a given session is valid by way of the
session_set_cookie_params()
function, the path can also be set via ini_set('session.cookie_path',
'/my/app/example')
note that session_name() and session_save_path() must be called before you
call session_start()
I recommend going through the info at http://php.net/manual/en/ref.session.php
in order to get a better 'feel' of how to use sessions 'properly'
- Ben
On 4/20/06, Dave Goodchild [EMAIL PROTECTED] wrote:
You can use ini_set to alter this value locally (until the script exits) in
the script itself, which saves having to use a separate ini file if that is
the only value you want to change.
On 20/04/06, Ben Liu [EMAIL PROTECTED] wrote:
Thanks for the response Robin, I'm reading up on session.cookie_path
now. It seems that this would require creating separate php.ini files
for each application.
On 4/20/06, Robin Vickery [EMAIL PROTECTED] wrote:
On 20/04/06, Ben Liu [EMAIL PROTECTED] wrote:
Hello All,
I'm using a single development server to host multiple client
projects, many of which require session management. I've noticed that
sometimes when I test these various web apps (which are simply in
separate sub directories) I get session leakage where logging in and
establishing a session on one app allows me access to (automatically
logs me in) to other app(s) on the same server. Or sometimes a session
variable will be set across all the apps, like $_SESSION['username'].
Is this due to the fact that sessions are established between client
browsers and servers, regardless of directory/sub directory?
Yes - that's the default behaviour, although if you set
session.cookie_path separately for each app, they shouldn't share
session cookies. You might also want to look at session.save_path
which will allow each app to save their session files in a different
location.
-robin
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
http://www.web-buddha.co.uk
dynamic web programming from Reigate, Surrey UK
look out for project karma, our new venture, coming soon!
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Session contamination?
Thanks Jochem, this should give me all I need to solve this problem. -Ben
On 4/20/06, Jochem Maas [EMAIL PROTECTED] wrote:
Ben Liu wrote:
Hi Dave,
Thanks, I think the method recommended by Robin using the function
ini_set() would work, but somehow I think this could be done in
simpler fashion by setting separate session names for each app, unless
I am misunderstanding the use of session_name(). Trying this out
now...
passing a different/unique value to session_name() should avoid inadvertent
contamination.
[http://php.net/manual/en/function.session-name.php]
Robin's second suggestion of setting the save path can be done with
session_save_path() as well as via ini_set().
[http://php.net/manual/en/function.session-save-path.php]
Robin's first suggestion is the one I would implement first, you can set the
[url]path for which a given session is valid by way of the
session_set_cookie_params()
function, the path can also be set via ini_set('session.cookie_path',
'/my/app/example')
note that session_name() and session_save_path() must be called before you
call session_start()
I recommend going through the info at http://php.net/manual/en/ref.session.php
in order to get a better 'feel' of how to use sessions 'properly'
- Ben
On 4/20/06, Dave Goodchild [EMAIL PROTECTED] wrote:
You can use ini_set to alter this value locally (until the script exits) in
the script itself, which saves having to use a separate ini file if that is
the only value you want to change.
On 20/04/06, Ben Liu [EMAIL PROTECTED] wrote:
Thanks for the response Robin, I'm reading up on session.cookie_path
now. It seems that this would require creating separate php.ini files
for each application.
On 4/20/06, Robin Vickery [EMAIL PROTECTED] wrote:
On 20/04/06, Ben Liu [EMAIL PROTECTED] wrote:
Hello All,
I'm using a single development server to host multiple client
projects, many of which require session management. I've noticed that
sometimes when I test these various web apps (which are simply in
separate sub directories) I get session leakage where logging in and
establishing a session on one app allows me access to (automatically
logs me in) to other app(s) on the same server. Or sometimes a session
variable will be set across all the apps, like $_SESSION['username'].
Is this due to the fact that sessions are established between client
browsers and servers, regardless of directory/sub directory?
Yes - that's the default behaviour, although if you set
session.cookie_path separately for each app, they shouldn't share
session cookies. You might also want to look at session.save_path
which will allow each app to save their session files in a different
location.
-robin
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
http://www.web-buddha.co.uk
dynamic web programming from Reigate, Surrey UK
look out for project karma, our new venture, coming soon!
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Session contamination?
Hi Dave, After a bit more research, I think I understand why Jochem recommends use of session_save_path() rather than just naming each session differently. The former method provides more security as you can set the location where session cookies are stored. This will help prevent an attacker from gaining access to session information and then using it to gain inappropriate access to the application the session was created for or even other applications running on the same shared server. Anyway, I think that's why. - Ben On 4/20/06, Dave Goodchild [EMAIL PROTECTED] wrote: Let me know how you get on. I have encountered the session leakage issue before also and it scared the willies out of me. On 20/04/06, Ben Liu [EMAIL PROTECTED] wrote: Hi Dave, Thanks, I think the method recommended by Robin using the function ini_set() would work, but somehow I think this could be done in simpler fashion by setting separate session names for each app, unless I am misunderstanding the use of session_name(). Trying this out now... - Ben On 4/20/06, Dave Goodchild [EMAIL PROTECTED] wrote: You can use ini_set to alter this value locally (until the script exits) in the script itself, which saves having to use a separate ini file if that is the only value you want to change. On 20/04/06, Ben Liu [EMAIL PROTECTED] wrote: Thanks for the response Robin, I'm reading up on session.cookie_path now. It seems that this would require creating separate php.ini files for each application. On 4/20/06, Robin Vickery [EMAIL PROTECTED] wrote: On 20/04/06, Ben Liu [EMAIL PROTECTED] wrote: Hello All, I'm using a single development server to host multiple client projects, many of which require session management. I've noticed that sometimes when I test these various web apps (which are simply in separate sub directories) I get session leakage where logging in and establishing a session on one app allows me access to (automatically logs me in) to other app(s) on the same server. Or sometimes a session variable will be set across all the apps, like $_SESSION['username']. Is this due to the fact that sessions are established between client browsers and servers, regardless of directory/sub directory? Yes - that's the default behaviour, although if you set session.cookie_path separately for each app, they shouldn't share session cookies. You might also want to look at session.save_path which will allow each app to save their session files in a different location. -robin -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- http://www.web-buddha.co.uk dynamic web programming from Reigate, Surrey UK look out for project karma, our new venture, coming soon! -- http://www.web-buddha.co.uk dynamic web programming from Reigate, Surrey UK look out for project karma, our new venture, coming soon! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Session contamination?
On Thu, April 20, 2006 10:21 am, Ben Liu wrote: I'm using a single development server to host multiple client projects, many of which require session management. I've noticed that sometimes when I test these various web apps (which are simply in separate sub directories) I get session leakage where logging in and establishing a session on one app allows me access to (automatically logs me in) to other app(s) on the same server. Or sometimes a session variable will be set across all the apps, like $_SESSION['username']. Is this due to the fact that sessions are established between client browsers and servers, regardless of directory/sub directory? What is the best way to avoid/prevent this problem? Should I be using specific Session ID's or Session names? Yes, the server and the browser are using: Domain Name Path SESSID (session_name + ID) You could change any one of those to distinguish Session IDs. The easiest would probably be: http://php.net/session_name Or you could just call it a feature like MS Passport... :-) -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Session contamination?
On Thu, April 20, 2006 1:46 pm, Ben Liu wrote: After a bit more research, I think I understand why Jochem recommends use of session_save_path() rather than just naming each session differently. The former method provides more security as you can set the location where session cookies are stored. This will help prevent an attacker from gaining access to session information and then using it to gain inappropriate access to the application the session was created for or even other applications running on the same shared server. Anyway, I think that's why. ::Possible False Sense Of Security Alert:: If a Bad Guy can read the session data, moving it to a different directory is probably not going to help, really... Unless you are running with different Usernames for each client on your shared server, using FastCGI + suexec or some similar method, the cookie files are STILL just as readable by the same Bad Guys, using the same methods. They just have to change their to: ?php $path = /other/path/to/other/cookies;? before they start their damage. There may well be other GREAT reasons for using a different save path, or a different path for the Cookie, or session_name over each other, but I don't think Security is the reason behind any of the choices. I'd personally use ini_set as the last choice because it's remotely possible that the setting can't be changed from within a script, as a few are like that -- Or, worse, that they can be changed today, but in, say PHP 6 or PHP 7, they won't be for some obscure reason we cannot predict today. session_name() seems less likely to just disappear completely as a feature than a minor change to a php.ini setting and where it is allowed. But that's just my paranoid logic. :-) -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
