Hi,
token does not work if cookies are disabled
of course the whole session thing does not work if cookies disabled, but till now this was not a problem as the session was just re-init with every request if the session could not be continued.
so phpMyAdmin now requires cookies enabled in browser.
Hi
On Thu, 27 Apr 2006 14:57:46 +0200 Sebastian Mendel lists@sebastianmendel.de wrote:
token does not work if cookies are disabled
of course the whole session thing does not work if cookies disabled, but till now this was not a problem as the session was just re-init with every request if the session could not be continued.
so phpMyAdmin now requires cookies enabled in browser.
I expected it to work and session ID being added to each request in libraries/url_generating.lib.php, why it is not done so?
Michal Čihař schrieb:
Hi
On Thu, 27 Apr 2006 14:57:46 +0200 Sebastian Mendel lists@sebastianmendel.de wrote:
token does not work if cookies are disabled
of course the whole session thing does not work if cookies disabled, but till now this was not a problem as the session was just re-init with every request if the session could not be continued.
so phpMyAdmin now requires cookies enabled in browser.
I expected it to work and session ID being added to each request in libraries/url_generating.lib.php, why it is not done so?
for security reasons we decided to not support url session ids
On Thu, 27 Apr 2006 15:18:34 +0200 Sebastian Mendel lists@sebastianmendel.de wrote:
for security reasons we decided to not support url session ids
What's problem with that?
Michal Čihař schrieb:
On Thu, 27 Apr 2006 15:18:34 +0200 Sebastian Mendel lists@sebastianmendel.de wrote:
for security reasons we decided to not support url session ids
What's problem with that?
session fixation and hijacking?
On Thu, 27 Apr 2006 15:29:31 +0200 Sebastian Mendel lists@sebastianmendel.de wrote:
Michal Čihař schrieb:
On Thu, 27 Apr 2006 15:18:34 +0200 Sebastian Mendel lists@sebastianmendel.de wrote:
for security reasons we decided to not support url session ids
What's problem with that?
session fixation and hijacking?
Hmmm, what is better? This or XSRF or cookie requirement. Looks like we have to make choice.
Michal Čihař schrieb:
On Thu, 27 Apr 2006 15:29:31 +0200 Sebastian Mendel lists@sebastianmendel.de wrote:
Michal Čihař schrieb:
On Thu, 27 Apr 2006 15:18:34 +0200 Sebastian Mendel lists@sebastianmendel.de wrote:
for security reasons we decided to not support url session ids
What's problem with that?
session fixation and hijacking?
Hmmm, what is better? This or XSRF or cookie requirement. Looks like we have to make choice.
whether url sid is allowed or not is set in session.inc.php possible we could add a $cfg to allow url sid - so it is the choice of the user if he allows sid via url or not
On Fri, 28 Apr 2006 10:38:36 +0200 Sebastian Mendel lists@sebastianmendel.de wrote:
whether url sid is allowed or not is set in session.inc.php possible we could add a $cfg to allow url sid - so it is the choice of the user if he allows sid via url or not
Yes, we should add config option for that. And add documentation note that we require cookies unless this is enabled.
Michal Čihař a écrit :
On Fri, 28 Apr 2006 10:38:36 +0200 Sebastian Mendel lists@sebastianmendel.de wrote:
whether url sid is allowed or not is set in session.inc.php possible we could add a $cfg to allow url sid - so it is the choice of the user if he allows sid via url or not
Yes, we should add config option for that. And add documentation note that we require cookies unless this is enabled.
I am not really in favor of this idea. I guess it's the old security versus usability issue.
On one hand, we have users who have control over their browser and who, for some reason, disable cookies.
On the other hand, many users are using PMA on a shared installation, on which they have no control about PMA config.
In practice, is the threat about sessions fixation/hijacking real?
P.S. In 2.8.1 we now have this cookies restriction but I don't think it's documented.
http://sourceforge.net/tracker/index.php?func=detail&aid=1497352&gro...
Marc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Marc Delisle schrieb:
Michal ?iha? a écrit :
On Fri, 28 Apr 2006 10:38:36 +0200 Sebastian Mendel lists@sebastianmendel.de wrote:
whether url sid is allowed or not is set in session.inc.php possible we could add a $cfg to allow url sid - so it is the choice of the user if he allows sid via url or not
Yes, we should add config option for that. And add documentation note that we require cookies unless this is enabled.
I am not really in favor of this idea. I guess it's the old security versus usability issue.
On one hand, we have users who have control over their browser and who, for some reason, disable cookies.
if i deny someone to remember my face i cannot blame on him asking me everytime who am i!
On the other hand, many users are using PMA on a shared installation, on which they have no control about PMA config.
In practice, is the threat about sessions fixation/hijacking real?
fixation: it is real, and very easy!
domain.tld/script.php?PHPSID=1234
and now i send you this link you click it and your session is run under the id 1234 - now i wait till you logged in and i can use this session id to call the page by myself and be logged in with your details
but of course this is not possible with PMA currently - as the auth is not handled with session!
hijacking same as above, just you don't send the url but catch it somewhere, f.e. at the router or proxy - did you never tried to copy the url from one brwoser to another? with cookie based session ids this will not work you found yourself always on the login screen, with url based session id it works!
- -- Sebastian Mendel
www.sebastianmendel.de
Sebastian Mendel a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Marc Delisle schrieb:
Michal ?iha? a écrit :
On Fri, 28 Apr 2006 10:38:36 +0200 Sebastian Mendel lists@sebastianmendel.de wrote:
whether url sid is allowed or not is set in session.inc.php possible we could add a $cfg to allow url sid - so it is the choice of the user if he allows sid via url or not
Yes, we should add config option for that. And add documentation note that we require cookies unless this is enabled.
I am not really in favor of this idea. I guess it's the old security versus usability issue.
On one hand, we have users who have control over their browser and who, for some reason, disable cookies.
if i deny someone to remember my face i cannot blame on him asking me everytime who am i!
On the other hand, many users are using PMA on a shared installation, on which they have no control about PMA config.
In practice, is the threat about sessions fixation/hijacking real?
fixation: it is real, and very easy!
domain.tld/script.php?PHPSID=1234
and now i send you this link you click it and your session is run under the id 1234 - now i wait till you logged in and i can use this session id to call the page by myself and be logged in with your details
but of course this is not possible with PMA currently - as the auth is not handled with session!
hijacking same as above, just you don't send the url but catch it somewhere, f.e. at the router or proxy - did you never tried to copy the url from one brwoser to another? with cookie based session ids this will not work you found yourself always on the login screen, with url based session id it works!
Thanks Sebastian,
can't we implement some of the countermeasures as explained in section 5 of this document? For example, binding the legitimate user's IP address to our session data?
http://www.acros.si/papers/session_fixation.pdf
Marc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi!
can't we implement some of the countermeasures as explained in section 5 of this document? For example, binding the legitimate user's IP address to our session data?
The most easy way to counter session fixation is to just perform a session_regenerate_id() after the login. This way, any "fixated" session will be changed to a random session ID after the credentials are entered.
Binding an IP address should IMHO be prevented, it's just security by obscurity and no "real" mean against intrusion.
Session hijacking is a more definite problem. IMHO exposing the session ID in the URL must be avoided at all costs. Thus, only allowing cookie-enabled logins is IMHO the best way to deal with it. PMA is a sensible application, thus specific browser settings should be applied to it. You can't expect a user to have security on his databases if he disallows cookies, so we shouldn't support this mode. That's my take, of course. ;)
Best regards, Garvin
- -- ++ Garvin Hicking | Web-Entwickler [PHP] | www.garv.in | ICQ 21392242 ++ Developer of | www.phpMyAdmin.net | www.s9y.org
++ Make me happy | http://wishes.garv.in
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Garvin Hicking schrieb:
Hi!
can't we implement some of the countermeasures as explained in section 5 of this document? For example, binding the legitimate user's IP address to our session data?
The most easy way to counter session fixation is to just perform a session_regenerate_id() after the login. This way, any "fixated" session will be changed to a random session ID after the credentials are entered.
Binding an IP address should IMHO be prevented, it's just security by obscurity and no "real" mean against intrusion.
and is not possible, user may switch proxies between requests (AOL) and proxies does not always provide Forwarded-For headers.
- -- Sebastian Mendel
www.sebastianmendel.de
Garvin Hicking a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi!
can't we implement some of the countermeasures as explained in section 5 of this document? For example, binding the legitimate user's IP address to our session data?
The most easy way to counter session fixation is to just perform a session_regenerate_id() after the login. This way, any "fixated" session will be changed to a random session ID after the credentials are entered.
Ok, but this would move our minimum PHP version to 4.3.2. Probably not too bad, see http://www.nexen.net/chiffres_cles/phpversion/php_statistics_for_april_2006....
But, as you say, there would still be the hijacking problem, so let's say that regenerating session id could be added in 2.9.x as an added security measure, not for allowing users to disable their cookies.
If we really make official the cookies restriction, I would like to document this and release 2.8.2 in a few days.
Marc
Binding an IP address should IMHO be prevented, it's just security by obscurity and no "real" mean against intrusion.
Session hijacking is a more definite problem. IMHO exposing the session ID in the URL must be avoided at all costs. Thus, only allowing cookie-enabled logins is IMHO the best way to deal with it. PMA is a sensible application, thus specific browser settings should be applied to it. You can't expect a user to have security on his databases if he disallows cookies, so we shouldn't support this mode. That's my take, of course. ;)
Best regards, Garvin
++ Garvin Hicking | Web-Entwickler [PHP] | www.garv.in | ICQ 21392242 ++ Developer of | www.phpMyAdmin.net | www.s9y.org
++ Make me happy | http://wishes.garv.in
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFEfZbOUZolOPYrUhYRAq65AKCvkx4kv4YocegmKMArSiM6Q2Y8nwCgvJ65 6UBlThf6WTs7ly7QyfzHnXk= =y+sf -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Marc!
The most easy way to counter session fixation is to just perform a session_regenerate_id() after the login. This way, any "fixated" session will be changed to a random session ID after the credentials are entered.
Ok, but this would move our minimum PHP version to 4.3.2. Probably not too bad, see http://www.nexen.net/chiffres_cles/phpversion/php_statistics_for_april_2006....
session_regenerate_id() can be emulated with session_start()...session_destroy()...session_start() commands for earlier versions, where you just copy the $_SESSION array to a temporary array, restart the session and be dealt with.
But, as you say, there would still be the hijacking problem, so let's say that regenerating session id could be added in 2.9.x as an added security measure, not for allowing users to disable their cookies.
Right, session fixation is only a (real)problem when URLs are used. So if we officially only support cookie-enabled sessions, the session regeneration would actually not even be necessary at all. But it would prevent possible future abuse having that in 2.9.x.
Best regards, Garvin
- -- ++ Garvin Hicking | Web-Entwickler [PHP] | www.garv.in | ICQ 21392242 ++ Developer of | www.phpMyAdmin.net | www.s9y.org
++ Make me happy | http://wishes.garv.in
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Marc Delisle schrieb:
Garvin Hicking a écrit : Hi!
can't we implement some of the countermeasures as explained in section 5 of this document? For example, binding the legitimate user's IP address to our session data?
The most easy way to counter session fixation is to just perform a session_regenerate_id() after the login. This way, any "fixated" session will be changed to a random session ID after the credentials are entered.
Ok, but this would move our minimum PHP version to 4.3.2. Probably not too bad, see http://www.nexen.net/chiffres_cles/phpversion/php_statistics_for_april_2006....
you can do this without session_regenerate_id() too
But, as you say, there would still be the hijacking problem, so let's say that regenerating session id could be added in 2.9.x as an added security measure, not for allowing users to disable their cookies.
but we have no hijacking problem - the login is not stored in the session!
- -- Sebastian Mendel
www.sebastianmendel.de
Sebastian Mendel a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Marc Delisle schrieb:
Garvin Hicking a écrit : Hi!
can't we implement some of the countermeasures as explained in section 5 of this document? For example, binding the legitimate user's IP address to our session data?
The most easy way to counter session fixation is to just perform a session_regenerate_id() after the login. This way, any "fixated" session will be changed to a random session ID after the credentials are entered.
Ok, but this would move our minimum PHP version to 4.3.2. Probably not too bad, see http://www.nexen.net/chiffres_cles/phpversion/php_statistics_for_april_2006....
you can do this without session_regenerate_id() too
But, as you say, there would still be the hijacking problem, so let's say that regenerating session id could be added in 2.9.x as an added security measure, not for allowing users to disable their cookies.
but we have no hijacking problem - the login is not stored in the session!
You're right. I forgot this because you talked about hijacking in a previous message :)
So, with a regenerating technique we could use URL-based session id and avoid our cookie restriction? :)
Marc
Sebastian Mendel
www.sebastianmendel.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32)
iD8DBQFEfaYlX/0lClpZDr4RAmRgAJ44J3X8iPWSIJNBr4h55L27WQZSbQCgihr2 fU1kyrTtuRiDKNjS+9CZ5pQ= =d9NF -----END PGP SIGNATURE-----
All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&da... _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Hi!
So, with a regenerating technique we could use URL-based session id and avoid our cookie restriction? :)
I have not read the source, so my question is: When not using cookies and having URL-based sessions, where else would you store another authentication token?
I don't think this is possible, because if a user doesn't have cookies, all there's left is HTTP Authentication [which only works with mod_php and not the CGI] and the URI. The URI can be hijacked, so...there's nothing left to store data in? All storage in $_SESSION will be available to the session-ID hijacker...
Best regards, Garvin
Garvin Hicking a écrit :
Hi!
So, with a regenerating technique we could use URL-based session id and avoid our cookie restriction? :)
I have not read the source, so my question is: When not using cookies and having URL-based sessions, where else would you store another authentication token?
Do you mean a future new auth mechanism?
Currently we have published that enabling cookies was only required with auth_type = 'cookie'. I am in favor of asking to enable cookies in all cases, it's just that we have to publish it evidently and do it soon, like in 2.8.2.
I don't think this is possible, because if a user doesn't have cookies, all there's left is HTTP Authentication [which only works with mod_php and not the CGI] and the URI. The URI can be hijacked, so...there's nothing left to store data in? All storage in $_SESSION will be available to the session-ID hijacker...
config.inc.php can store fixed auth data and we support this...
Marc
Best regards, Garvin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Marc!
I have not read the source, so my question is: When not using cookies and having URL-based sessions, where else would you store another authentication token?
Do you mean a future new auth mechanism?
No, I was talking about your proposal :)
Currently we have published that enabling cookies was only required with auth_type = 'cookie'. I am in favor of asking to enable cookies in all cases, it's just that we have to publish it evidently and do it soon, like in 2.8.2.
I think publishing that is a good thing.
I don't think this is possible, because if a user doesn't have cookies, all there's left is HTTP Authentication [which only works with mod_php and not the CGI] and the URI. The URI can be hijacked, so...there's nothing left to store data in? All storage in $_SESSION will be available to the session-ID hijacker...
config.inc.php can store fixed auth data and we support this...
Yes, but that would still mean that with a hijacked session ID in the URL you could do everything that the "real" person could do - and you were explicitly asking if there is a way to:
* Do not use cookies * Use session storage * Use session ID propagation through URL * Be not subject to session hijacking
IMHO there is no way to make that happen.
Best regards, Garvin
- -- ++ Garvin Hicking | Web-Entwickler [PHP] | www.garv.in | ICQ 21392242 ++ Developer of | www.phpMyAdmin.net | www.s9y.org
++ Make me happy | http://wishes.garv.in
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Garvin Hicking schrieb:
Hi Marc!
I have not read the source, so my question is: When not using cookies and having URL-based sessions, where else would you store another authentication token?
Do you mean a future new auth mechanism?
No, I was talking about your proposal :)
Currently we have published that enabling cookies was only required with auth_type = 'cookie'. I am in favor of asking to enable cookies in all cases, it's just that we have to publish it evidently and do it soon, like in 2.8.2.
I think publishing that is a good thing.
I don't think this is possible, because if a user doesn't have cookies, all there's left is HTTP Authentication [which only works with mod_php and not the CGI] and the URI. The URI can be hijacked, so...there's nothing left to store data in? All storage in $_SESSION will be available to the session-ID hijacker...
config.inc.php can store fixed auth data and we support this...
Yes, but that would still mean that with a hijacked session ID in the URL you could do everything that the "real" person could do - and you were explicitly
you don't need to hijack this session - the login credentials are stored in the cfg, you just need to open the url!
asking if there is a way to:
- Do not use cookies
- Use session storage
- Use session ID propagation through URL
- Be not subject to session hijacking
IMHO there is no way to make that happen.
at the moment this is possible only with http-auth
with session id regenerating it is fare more difficult to hijack a session - but not impossible
it seems to me that you forget that session and login is not the same in PMA (at least at the moment)!
at the moment an user has only the choice between cookie-, http- or config-auth - but all this has nothing to do with session!
- -- Sebastian Mendel
www.sebastianmendel.de
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Marc Delisle schrieb:
Sebastian Mendel a écrit : Marc Delisle schrieb:
Garvin Hicking a écrit : Hi!
can't we implement some of the countermeasures as explained in section 5 of this document? For example, binding the legitimate user's IP address to our session data?
The most easy way to counter session fixation is to just perform a session_regenerate_id() after the login. This way, any "fixated" session will be changed to a random session ID after the credentials are entered.
Ok, but this would move our minimum PHP version to 4.3.2. Probably not too bad, see http://www.nexen.net/chiffres_cles/phpversion/php_statistics_for_april_2006....
you can do this without session_regenerate_id() too
But, as you say, there would still be the hijacking problem, so let's say that regenerating session id could be added in 2.9.x as an added security measure, not for allowing users to disable their cookies.
but we have no hijacking problem - the login is not stored in the session!
You're right. I forgot this because you talked about hijacking in a previous message :)
yes, but i also mentioned: "but of course this [hijacking/fixation] is not possible with PMA currently - as the auth is not handled with session!"
So, with a regenerating technique we could use URL-based session id and avoid our cookie restriction? :)
phpMyadmin is not just any web application it is an administration tool! and i think we can demand from our customers to accept cookies for her own security!
whether it is possible at the moment to make any use out of a hijacked session-id or not!
we should try to be as secure as possible from the start!
and if it is really really really required to use url based session id than we could introduce a config switch to enable this - but i think most ISP will never set this to true (even more i think if it would be enabled by default most will set it to false) as most ISP now if something goes wrong the customers blame on them (the ISP) and not on them self!
- -- Sebastian Mendel
www.sebastianmendel.de
On Fri, 28 Apr 2006 10:38:36 +0200 Sebastian Mendel lists@sebastianmendel.de wrote:
Michal Čihař schrieb:
On Thu, 27 Apr 2006 15:29:31 +0200 Sebastian Mendel lists@sebastianmendel.de wrote:
Michal Čihař schrieb:
On Thu, 27 Apr 2006 15:18:34 +0200 Sebastian Mendel lists@sebastianmendel.de wrote:
for security reasons we decided to not support url session ids
What's problem with that?
session fixation and hijacking?
Hmmm, what is better? This or XSRF or cookie requirement. Looks like we have to make choice.
whether url sid is allowed or not is set in session.inc.php
IMHO it is allowed there:
// but not all user allow cookies ini_set('session.use_only_cookies', false); ini_set('session.use_trans_sid', true);
Or am I missing some other ini option that disables it completely?
-
Garvin Hicking -
Marc Delisle -
Michal Čihař -
Sebastian Mendel