Hi,
with sessions/cookies the different window names (required for querywindow) can be easily stored in the session/cookie
so this would be accessible from everywhere without annoying javascript
(also the javascritp capabilty of the browser at all, can be stored there to get rid of this noscript constructs everywhere)
was there any discusions regarding sessions in the past? are there any important points that speak against sessions?
Hi
On Tue 27. 9. 2005 11:17, Sebastian Mendel wrote:
with sessions/cookies the different window names (required for querywindow) can be easily stored in the session/cookie
so this would be accessible from everywhere without annoying javascript
(also the javascritp capabilty of the browser at all, can be stored there to get rid of this noscript constructs everywhere)
was there any discusions regarding sessions in the past? are there any important points that speak against sessions?
There was discussion in far away past, which lead to consensus that we can not use sessions until they're natively in PHP. As you can see, it was in times of PHP 3 :-).
In fact sessions could solve lot of problems with redirects and large SQL queries we have, however nobody has yet implemented that.
If you're going to implement this, do not forget that sessions should work also without cookies enabled.
Hi!
(I can only agree to what Michal said - it's only not implemented because nobody got down to do it)
If you're going to implement this, do not forget that sessions should work also without cookies enabled.
There is also a problem about which Marc and I talked in the past. We should not store sensitive information like passwords in sessions, as usually all session data can be accessed from untrusted users on the same webserver, as session files are readable for everyone usually.
Also we need to think about what bad can happen when someone hijacks your session id, or uses session fixation.
Regards, Garvin
Garvin Hicking wrote:
Hi!
(I can only agree to what Michal said - it's only not implemented because nobody got down to do it)
If you're going to implement this, do not forget that sessions should work also without cookies enabled.
There is also a problem about which Marc and I talked in the past. We should not store sensitive information like passwords in sessions, as usually all session data can be accessed from untrusted users on the same webserver, as session files are readable for everyone usually.
securing session data/handling is part of the system not of the application (like some days ago someone said window hijacking is part of the browser not the app)
even with open_basedir disabled, to open a file from the tmp dir you need the exact name, as normaly listing dir contents is not allowed
and guessing the right session id is nearly impossible:
--- ; Select a hash function ; 0: MD5 (128 bits) ; 1: SHA-1 (160 bits) session.hash_function = 0
; Define how many bits are stored in each character when converting ; the binary hash data to something readable. ; ; 4 bits: 0-9, a-f ; 5 bits: 0-9, a-v ; 6 bits: 0-9, a-z, A-Z, "-", "," session.hash_bits_per_character = 5 ---
Also we need to think about what bad can happen when someone hijacks your session id, or uses session fixation.
authentication information does not require to be stored in the session! authentication system can stay as it is!
Hi!
securing session data/handling is part of the system not of the application (like some days ago someone said window hijacking is part of the browser not the app)
We would make it too easy for us to say so, especially if we are able to bypass this. If we really just use PHP sessions and pay no attention to their security, we need to make phpMyAdmin still work without sessions. Most of the shared hosting providers to not ensure different session.save_path settings...
even with open_basedir disabled, to open a file from the tmp dir you need the exact name, as normaly listing dir contents is not allowed
Why do you think that? I can open and list my /tmp directory on all 3 hosts I just checked:
<?php $d = opendir('/tmp'); while (($file = readdir($d)) !== false) { echo $file . "\n"; }
and guessing the right session id is nearly impossible:
That's true of course. :)
Also we need to think about what bad can happen when someone hijacks your session id, or uses session fixation.
authentication information does not require to be stored in the session! authentication system can stay as it is!
Yes, I think it's better to rely on the current system than to use a (much easier) PHP session auth.
Regards, Garvin
Garvin Hicking wrote:
Hi!
securing session data/handling is part of the system not of the application (like some days ago someone said window hijacking is part of the browser not the app)
We would make it too easy for us to say so, especially if we are able to bypass this. If we really just use PHP sessions and pay no attention to their security, we need to make phpMyAdmin still work without sessions. Most of the shared hosting providers to not ensure different session.save_path settings...
ok, so lets just start with insensitive data, like charset/lang, selected server/db/table, configuration, windownames aso, query history, aso.
even with open_basedir disabled, to open a file from the tmp dir you need the exact name, as normaly listing dir contents is not allowed
Why do you think that? I can open and list my /tmp directory on all 3 hosts I just checked:
<?php $d = opendir('/tmp'); while (($file = readdir($d)) !== false) { echo $file . "\n"; }
uuh, bad, this is really a misconfiguration! the web (apache and/or php) user should not have read access an this directory! only on the files created by themselves in there!
Hi!
<?php $d = opendir('/tmp'); while (($file = readdir($d)) !== false) { echo $file . "\n"; }
uuh, bad, this is really a misconfiguration! the web (apache and/or php) user should not have read access an this directory! only on the files created by themselves in there!
You are right, I messed this up myself by making /tmp world-writable. Sorry for the hassle. :)
Regards, Garvin
Garvin Hicking wrote:
Hi!
<?php $d = opendir('/tmp'); while (($file = readdir($d)) !== false) { echo $file . "\n"; }
uuh, bad, this is really a misconfiguration! the web (apache and/or php) user should not have read access an this directory! only on the files created by themselves in there!
You are right, I messed this up myself by making /tmp world-writable. Sorry for the hassle. :)
world writable is _not_ wrong, world readable is wrong! ;-)
Sebastian Mendel a écrit :
Garvin Hicking wrote:
Hi!
<?php $d = opendir('/tmp'); while (($file = readdir($d)) !== false) { echo $file . "\n"; }
uuh, bad, this is really a misconfiguration! the web (apache and/or php) user should not have read access an this directory! only on the files created by themselves in there!
You are right, I messed this up myself by making /tmp world-writable. Sorry for the hassle. :)
world writable is _not_ wrong, world readable is wrong! ;-)
/tmp has always been world readable and writable!
Marc
Garvin Hicking a écrit :
Hi!
<?php $d = opendir('/tmp'); while (($file = readdir($d)) !== false) { echo $file . "\n"; }
uuh, bad, this is really a misconfiguration! the web (apache and/or php) user should not have read access an this directory! only on the files created by themselves in there!
You are right, I messed this up myself by making /tmp world-writable. Sorry for the hassle. :)
Regards, Garvin
/tmp has always been world-writable, and IMO it should stay this way. This is the very goal of this directory. The problem comes from using /tmp for session data.
Marc
Garvin Hicking a écrit :
Hi!
securing session data/handling is part of the system not of the application (like some days ago someone said window hijacking is part of the browser not the app)
We would make it too easy for us to say so, especially if we are able to bypass this. If we really just use PHP sessions and pay no attention to their security, we need to make phpMyAdmin still work without sessions. Most of the shared hosting providers to not ensure different session.save_path settings...
even with open_basedir disabled, to open a file from the tmp dir you need the exact name, as normaly listing dir contents is not allowed
Why do you think that? I can open and list my /tmp directory on all 3 hosts I just checked:
<?php $d = opendir('/tmp'); while (($file = readdir($d)) !== false) { echo $file . "\n"; }
and guessing the right session id is nearly impossible:
That's true of course. :)
Also we need to think about what bad can happen when someone hijacks your session id, or uses session fixation.
authentication information does not require to be stored in the session! authentication system can stay as it is!
But.... users deactivating cookies in their browser currently cannot benefit from the login panel.
Yes, I think it's better to rely on the current system than to use a (much easier) PHP session auth.
Regards, Garvin
Garvin Hicking a écrit :
Hi!
(I can only agree to what Michal said - it's only not implemented because nobody got down to do it)
If you're going to implement this, do not forget that sessions should work also without cookies enabled.
I agree with sessions. Even if we ask as a requirement PHP 4.1.0 minimum, maybe it's better to have the choice of using sessions or not. We could look the possibility of using some kind of plugin mechanism for passing data.
There is also a problem about which Marc and I talked in the past. We should not store sensitive information like passwords in sessions, as usually all session data can be accessed from untrusted users on the same webserver, as session files are readable for everyone usually.
We currently use blowfish for hiding user name and password in the cookies, so we should continue this way with sessions. But other sensitive data contained in a query (a social security number, for example) may find it's way in session data, so we have to deal with this. Encrypt everything? With mcrypt it would not be too bad, without mcrypt, ouch.
Also we need to think about what bad can happen when someone hijacks your session id, or uses session fixation.
Regards, Garvin
Marc Delisle wrote:
Garvin Hicking a écrit :
Hi!
(I can only agree to what Michal said - it's only not implemented because nobody got down to do it)
If you're going to implement this, do not forget that sessions should work also without cookies enabled.
I agree with sessions. Even if we ask as a requirement PHP 4.1.0
from the PMA docu:
You need PHP 4.1.0 or newer (*)
;-), nothing changes ...
minimum, maybe it's better to have the choice of using sessions or not. We could look the possibility of using some kind of plugin mechanism for passing data.
There is also a problem about which Marc and I talked in the past. We should not store sensitive information like passwords in sessions, as usually all session data can be accessed from untrusted users on the same webserver, as session files are readable for everyone usually.
We currently use blowfish for hiding user name and password in the cookies, so we should continue this way with sessions. But other sensitive data contained in a query (a social security number, for example) may find it's way in session data, so we have to deal with this. Encrypt everything? With mcrypt it would not be too bad, without mcrypt, ouch.
you speaking about storing results in the session?
in most cases, i think, it would not be faster storing a result in the session than query the database again! - so store results in the session makes no sense - only for slow querys - and this can be a configuration thing -
scfg['SaveSlowQueryResultsInSession']
Sebastian Mendel a écrit :
Marc Delisle wrote:
Garvin Hicking a écrit :
Hi!
(I can only agree to what Michal said - it's only not implemented because nobody got down to do it)
If you're going to implement this, do not forget that sessions should work also without cookies enabled.
I agree with sessions. Even if we ask as a requirement PHP 4.1.0
from the PMA docu:
You need PHP 4.1.0 or newer (*)
;-), nothing changes ...
minimum, maybe it's better to have the choice of using sessions or not. We could look the possibility of using some kind of plugin mechanism for passing data.
There is also a problem about which Marc and I talked in the past. We should not store sensitive information like passwords in sessions, as usually all session data can be accessed from untrusted users on the same webserver, as session files are readable for everyone usually.
We currently use blowfish for hiding user name and password in the cookies, so we should continue this way with sessions. But other sensitive data contained in a query (a social security number, for example) may find it's way in session data, so we have to deal with this. Encrypt everything? With mcrypt it would not be too bad, without mcrypt, ouch.
you speaking about storing results in the session?
Not results but queries: select * from employee where ssn=123456789
in most cases, i think, it would not be faster storing a result in the session than query the database again! - so store results in the session makes no sense - only for slow querys - and this can be a configuration thing -
scfg['SaveSlowQueryResultsInSession']
-
Garvin Hicking -
Marc Delisle -
Michal Čihař -
Sebastian Mendel