HI all,
I think most of concerns for session_regenerate_id() is discussed.
I would like to finish this RFC.
Following RFC was made to change session_regenerate_id(TRUE) by default.
I was initially tried to remove old session data immediately with this RFC,
but
it turned out we should care about reliability more in real world
environment.
Secure session_regenerate_id()
https://wiki.php.net/rfc/session_regenerate_id
The time stamp could be outside of of $_SESSION. It requires BC
modification in
serializer and/or save handler. It would be complex and possibly slower
depend
on implementation.
I hope it's precise enough and easy to understand idea behind it.
If you have suggestions, it would be appreciated.
Names can be anything, especially.
If I'm missing something, please let me know.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
HI all,
I think most of concerns for
session_regenerate_id()is discussed.
I would like to finish this RFC.Following RFC was made to change session_regenerate_id(TRUE) by default.
I was initially tried to remove old session data immediately with this RFC,
but
it turned out we should care about reliability more in real world
environment.Secure
session_regenerate_id()
https://wiki.php.net/rfc/session_regenerate_idThe time stamp could be outside of of $_SESSION. It requires BC
modification in
serializer and/or save handler. It would be complex and possibly slower
depend
on implementation.I hope it's precise enough and easy to understand idea behind it.
If you have suggestions, it would be appreciated.
Names can be anything, especially.If I'm missing something, please let me know.
Hi Yasuo,
[...]
Errors may be raised for either legitimate user or attacker. If error is
raised for legitimate user, legitimate user could know they are under attack.
(Possibly network is dangerous or app has vulnerability) If error is raised
for attacker, attacker could know they might be caught by illegal access.
[...]
I wonder how many legitimate users will realize they're under attack. For
average user it will look like application does weird things (i.e. logout
immediately). If network is dangerous or app has vulnerability then we cannot
fix the problem - you can't make n-th layer secure if (n-1)-th layer is
insecure.
[...]
Stealing session ID is easy regardless of HTTPS. Attacker can set up fake
router by ARP spoofing. Most networks do not have ARP spoofing prevention,
even detection. For HTTP, attacker can view session ID simply. For HTTPS,
attacker can set up transparent HTTPS stripping proxy and steal session ID.
Most users do not care much if they are connecting via HTTPS or not.
[...]
What if application uses secure attribute on session cookie? We've got already
session.cookie_secure setting which seems to solve the issue. I don't see how
by introducing your proposal will make situation better. If application allows
login and operates as user without HTTPS, then it's not our problem.
[...]
Problem of immediate old session deletion:
Make session ID regeneration unreliable. (Unacceptable)
[...]
I haven't found single issue in
bugs.php.net that session_regenerate_id(TRUE) is a problem to any user.
[...]
Remove alarm for possible attacks. (No detection = Insecure)
Make sure old session is deleted certain period and Raise
error/exception for invalid access provides much better security than
current way or immediate deletion.
[...]
What you mean by "No detection = Insecure"?
Kind Regrads,
Mateusz Kocielski
Hi Mateusz,
On Wed, Mar 19, 2014 at 5:02 PM, Mateusz Kocielski shm@digitalsun.plwrote:
[...]
Errors may be raised for either legitimate user or attacker. If error is
raised for legitimate user, legitimate user could know they are under
attack.
(Possibly network is dangerous or app has vulnerability) If error is raised
for attacker, attacker could know they might be caught by illegal access.
[...]I wonder how many legitimate users will realize they're under attack. For
average user it will look like application does weird things (i.e. logout
immediately). If network is dangerous or app has vulnerability then we
cannot
fix the problem - you can't make n-th layer secure if (n-1)-th layer is
insecure.
It depends on how developer treats possible attack. Session manager raises
exception only. Developer may ignore or give detailed information about the
risk in their page.
My proposal does not alert victims/attackers automatically, but only give
tools for developers.
How to use tools is up to developers.
[...]
Stealing session ID is easy regardless of HTTPS. Attacker can set up fake
router by ARP spoofing. Most networks do not have ARP spoofing prevention,
even detection. For HTTP, attacker can view session ID simply. For HTTPS,
attacker can set up transparent HTTPS stripping proxy and steal session ID.
Most users do not care much if they are connecting via HTTPS or not.
[...]What if application uses secure attribute on session cookie? We've got
already
session.cookie_secure setting which seems to solve the issue. I don't see
how
by introducing your proposal will make situation better. If application
allows
login and operates as user without HTTPS, then it's not our problem.
Secure attribute does not matter if attacker is stripping HTTPS.
I'm having hard time to explain why "detection" is better for security.
Surveillance camera does not "prevent" crime, but "identify" who did.
Surveillance cameras are good for security.
BTW, almost all security measures are "mitigation".
Security measure does not have to "remove risk", but mitigates risk like
HTTPS.
Do you agree that HTTPS is security measure, right?
[...]
Problem of immediate old session deletion:
Make session ID regeneration unreliable. (Unacceptable)[...]
I haven't found single issue in
bugs.php.net that session_regenerate_id(TRUE) is a problem to any user.
Of course, there aren't. session_regenerate_id(FALSE) is the default now and
random logout by race condition is hard to be noticed by developers.
[...]
Remove alarm for possible attacks. (No detection = Insecure)
Make sure old session is deleted certain period and Raise
error/exception for invalid access provides much better security than
current way or immediate deletion.
[...]What you mean by "No detection = Insecure"?
I think I've answered this in previous comment.
Thank you for asking question.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
[...]
Errors may be raised for either legitimate user or attacker. If error is
raised for legitimate user, legitimate user could know they are under
attack.
(Possibly network is dangerous or app has vulnerability) If error is raised
for attacker, attacker could know they might be caught by illegal access.
[...]I wonder how many legitimate users will realize they're under attack. For
average user it will look like application does weird things (i.e. logout
immediately). If network is dangerous or app has vulnerability then we
cannot
fix the problem - you can't make n-th layer secure if (n-1)-th layer is
insecure.It depends on how developer treats possible attack. Session manager raises
exception only. Developer may ignore or give detailed information about the
risk in their page.My proposal does not alert victims/attackers automatically, but only give
tools for developers.
How to use tools is up to developers.[...]
Stealing session ID is easy regardless of HTTPS. Attacker can set up fake
router by ARP spoofing. Most networks do not have ARP spoofing prevention,
even detection. For HTTP, attacker can view session ID simply. For HTTPS,
attacker can set up transparent HTTPS stripping proxy and steal session ID.
Most users do not care much if they are connecting via HTTPS or not.
[...]What if application uses secure attribute on session cookie? We've got
already
session.cookie_secure setting which seems to solve the issue. I don't see
how
by introducing your proposal will make situation better. If application
allows
login and operates as user without HTTPS, then it's not our problem.Secure attribute does not matter if attacker is stripping HTTPS.
You're right. But if user runs over transparent stripping proxy, then managing
session by an attacker is easy (attacker replaces set-cookie from server
to victim with own value, and sends proper session on every user request).
User won't have an idea that something is wrong. Simply, running without https
in insecure environment is asking for trouble and what you prospose won't help
in this case.
I'm having hard time to explain why "detection" is better for security.
Surveillance camera does not "prevent" crime, but "identify" who did.
Surveillance cameras are good for security.
I agree. But we've got more factors here, it's not a simple tool for detection
of crimes. If we let "old session" live for x secs, what will happen to
changes done to the old session? How do you want to resolve that? We should
find a balance between complexity and security.
BTW, almost all security measures are "mitigation".
Security measure does not have to "remove risk", but mitigates risk like
HTTPS.
Do you agree that HTTPS is security measure, right?
Yes.
[...]
Problem of immediate old session deletion:
Make session ID regeneration unreliable. (Unacceptable)[...]
I haven't found single issue in
bugs.php.net that session_regenerate_id(TRUE) is a problem to any user.Of course, there aren't. session_regenerate_id(FALSE) is the default now and
random logout by race condition is hard to be noticed by developers.
You might be right, I just found [1]. Note the shadowhand's post:
[...]
I think developers should be aware of the fact that HTTP is a stateless
protocol and work around that fact, not try to "fix" it with hacks that will,
with all due respect, end up causing more issues than they solve.
[...]
Thanks for your answers.
[1] -
http://forum.kohanaframework.org/discussion/1870/race-conditions-in-session-handling/p1
Kind Reagards,
Mateusz Kocielski
Hi Meteusz,
On Wed, Mar 19, 2014 at 8:11 PM, Mateusz Kocielski shm@digitalsun.plwrote:
login and operates as user without HTTPS, then it's not our problem.
Secure attribute does not matter if attacker is stripping HTTPS.
You're right. But if user runs over transparent stripping proxy, then
managing
session by an attacker is easy (attacker replaces set-cookie from server
to victim with own value, and sends proper session on every user request).
User won't have an idea that something is wrong. Simply, running without
https
in insecure environment is asking for trouble and what you prospose won't
help
in this case.
Security measures are mitigation. HTTPS could be useless. It's the same.
I'm having hard time to explain why "detection" is better for security.
Surveillance camera does not "prevent" crime, but "identify" who did.
Surveillance cameras are good for security.I agree. But we've got more factors here, it's not a simple tool for
detection
of crimes. If we let "old session" live for x secs, what will happen to
changes done to the old session? How do you want to resolve that? We should
find a balance between complexity and security.
Currently we have poor mitigation. My proposal provides better mitigation.
BTW, almost all security measures are "mitigation".
Security measure does not have to "remove risk", but mitigates risk like
HTTPS.
Do you agree that HTTPS is security measure, right?Yes.
[...]
Problem of immediate old session deletion:
Make session ID regeneration unreliable. (Unacceptable)[...]
I haven't found single issue in
bugs.php.net that session_regenerate_id(TRUE) is a problem to any
user.Of course, there aren't. session_regenerate_id(FALSE) is the default now
and
random logout by race condition is hard to be noticed by developers.You might be right, I just found [1]. Note the shadowhand's post:
[...]
I think developers should be aware of the fact that HTTP is a stateless
protocol and work around that fact, not try to "fix" it with hacks that
will,
with all due respect, end up causing more issues than they solve.
[...]
I agree with his/her opinion. HTTP is stateless and we cannot force client
to
synchronize session ID. I'm proposing better/stricter work around than now.
http://forum.kohanaframework.org/discussion/1870/race-conditions-in-session-handling/p1
Thank you for the link.
Regards.
--
Yasuo Ohgaki
yohgaki@ohgaki.net
I agree. But we've got more factors here, it's not a simple tool for
detection
of crimes. If we let "old session" live for x secs, what will happen to
changes done to the old session? How do you want to resolve that? We should
find a balance between complexity and security.Currently we have poor mitigation. My proposal provides better mitigation.
I still don't see how you want to handle inconsistency between sessions. It
seems that your RFC silently ignores that issue.
Kind Regards,
Mateusz Kocielski
Hi Mateusz,
On Thu, Mar 20, 2014 at 5:23 PM, Mateusz Kocielski shm@digitalsun.plwrote:
I agree. But we've got more factors here, it's not a simple tool for
detection
of crimes. If we let "old session" live for x secs, what will happen to
changes done to the old session? How do you want to resolve that? We
should
find a balance between complexity and security.Currently we have poor mitigation. My proposal provides better
mitigation.I still don't see how you want to handle inconsistency between sessions. It
seems that your RFC silently ignores that issue.
I'm not sure which inconsistency. Could you specify/describe it?
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Mateusz,
On Thu, Mar 20, 2014 at 5:23 PM, Mateusz Kocielski shm@digitalsun.plwrote:
I agree. But we've got more factors here, it's not a simple tool for
detection
of crimes. If we let "old session" live for x secs, what will happen to
changes done to the old session? How do you want to resolve that? We
should
find a balance between complexity and security.Currently we have poor mitigation. My proposal provides better
mitigation.I still don't see how you want to handle inconsistency between sessions. It
seems that your RFC silently ignores that issue.I'm not sure which inconsistency. Could you specify/describe it?
Consider following scenario:
- session_regenerate_id(..) is called
- request to /update_session with old session id is done (some key-value in
session is changed) - with your change this request will succeed
--- from here user uses only new session - - updated key-value is missing in new session
(same scenario can be triggered now if old session is not deleted)
Kind Regards,
Mateusz Kocielski
Hi Mateusz,
On Thu, Mar 20, 2014 at 6:13 PM, Mateusz Kocielski shm@digitalsun.plwrote:
Hi Mateusz,
On Thu, Mar 20, 2014 at 5:23 PM, Mateusz Kocielski <shm@digitalsun.pl
wrote:I agree. But we've got more factors here, it's not a simple tool
for
detection
of crimes. If we let "old session" live for x secs, what will
happen to
changes done to the old session? How do you want to resolve that?
We
should
find a balance between complexity and security.Currently we have poor mitigation. My proposal provides better
mitigation.I still don't see how you want to handle inconsistency between
sessions. It
seems that your RFC silently ignores that issue.I'm not sure which inconsistency. Could you specify/describe it?
Consider following scenario:
- session_regenerate_id(..) is called
- request to /update_session with old session id is done (some key-value
in
session is changed) - with your change this request will succeed
--- from here user uses only new session -- updated key-value is missing in new session
(same scenario can be triggered now if old session is not deleted)
This race condition will not change with or without my proposal.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi,
Consider following scenario:
- session_regenerate_id(..) is called
- request to /update_session with old session id is done (some key-value
in
session is changed) - with your change this request will succeed
--- from here user uses only new session -- updated key-value is missing in new session
(same scenario can be triggered now if old session is not deleted)
This race condition will not change with or without my proposal.
Which is another reason to leave this to user code:
ajax_safe_regenerate_id($delete = TRUE)
{
if ( ! empty($_SERVER['HTTP_X_REQUESTED_WITH']) &&
strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) === 'xmlhttprequest')
{
return FALSE;
}
return session_regenerate_id($delete);
}
Cheers,
Andrey.
This race condition will not change with or without my proposal.
Which is another reason to leave this to user code:
ajax_safe_regenerate_id($delete = TRUE)
{
if ( ! empty($_SERVER['HTTP_X_REQUESTED_WITH']) &&
strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) === 'xmlhttprequest')
{
return FALSE;
}return session_regenerate_id($delete);}
This is not going to work properly, there's still race. I think that the best
solution is to handle race on client side (send request once more on session
error).
Kind Regrads,
Mateusz Kocielski
Hi,
This race condition will not change with or without my proposal.
Which is another reason to leave this to user code:
ajax_safe_regenerate_id($delete = TRUE)
{
if ( ! empty($_SERVER['HTTP_X_REQUESTED_WITH']) &&
strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) === 'xmlhttprequest')
{
return FALSE;
}return session_regenerate_id($delete);}
This is not going to work properly, there's still race. I think that the best
solution is to handle race on client side (send request once more on session
error).
There's no race condition, because there's no regeneration if the
request is done through Ajax (provided that the X-Requested-With
header is sent to tell us about that, which popular JS frameworks do),
that is the root cause of the problem.
But the bottom line is - it depends on client side implementation, and
this is an application design detail. It can't be solved by PHP.
Cheers,
Andrey.
Hi Mateusz,
On Thu, Mar 20, 2014 at 6:13 PM, Mateusz Kocielski shm@digitalsun.plwrote:
Hi Mateusz,
On Thu, Mar 20, 2014 at 5:23 PM, Mateusz Kocielski <shm@digitalsun.pl
wrote:I agree. But we've got more factors here, it's not a simple tool
for
detection
of crimes. If we let "old session" live for x secs, what will
happen to
changes done to the old session? How do you want to resolve that?
We
should
find a balance between complexity and security.Currently we have poor mitigation. My proposal provides better
mitigation.I still don't see how you want to handle inconsistency between
sessions. It
seems that your RFC silently ignores that issue.I'm not sure which inconsistency. Could you specify/describe it?
Consider following scenario:
- session_regenerate_id(..) is called
- request to /update_session with old session id is done (some key-value
in
session is changed) - with your change this request will succeed
--- from here user uses only new session -- updated key-value is missing in new session
(same scenario can be triggered now if old session is not deleted)
This race condition will not change with or without my proposal.
I should be more precise.
This race condition will be problem with future RFC not written yet.
Problem is a little differ, though. It's addressed and there is solution
for it.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi!
Secure
session_regenerate_id()
https://wiki.php.net/rfc/session_regenerate_id
Reading this RFC, I have the following thoughts:
-
The name is a misnomer. session_regenerate_id is secure with "true"
setting that deletes the session immediately. There's no security
problem there. There might be usability problem for those that want to
keep session around longer, but that's a different thing. Claiming that
this RFC is necessary for secure session regeneration is not correct. -
This functionality (limited-time soft deletion) can be very easily
implemented in user-space - just add the timestamp before doing the
regenerate and then checking for that variable in session_start. The
amount of code that needs to be added is very small so I don't see why
it requires any changes in the engine. -
Session functions never threw exceptions and making them throw
exceptions would break existing code, resulting in fatal errors. I don't
think it is a good idea to do such thing in a minor version. If we move
in next major to more widespread exception usage, it'd be fine but such
as it is now, exceptions would certainly not be expected coming from
session_start.
I'm also not sure what such exception would be useful for. So, say,
somebody accesses your site with stale session. You can not know if it
were an attack or just some user clicking an old link with a stale
cookie. You can not do anything with it but issue new session. So why
have that exception at all?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi Stas,
On Thu, Mar 20, 2014 at 3:35 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Secure
session_regenerate_id()
https://wiki.php.net/rfc/session_regenerate_idReading this RFC, I have the following thoughts:
- The name is a misnomer. session_regenerate_id is secure with "true"
setting that deletes the session immediately. There's no security
problem there. There might be usability problem for those that want to
keep session around longer, but that's a different thing. Claiming that
this RFC is necessary for secure session regeneration is not correct.
Strictly speaking, your view would be right. I don't mind giving better name
for this RFC. Any suggestion?
I'm recognizing reliability/availability as a part of security.
ISO 27000 defines it's a part of security.
- This functionality (limited-time soft deletion) can be very easily
implemented in user-space - just add the timestamp before doing the
regenerate and then checking for that variable in session_start. The
amount of code that needs to be added is very small so I don't see why
it requires any changes in the engine.
User may/can do this. I see this as task of HTTP session manager.
Session manager can do this task and users don't have to know they
must have it. It will provide better security for many applications/users.
Secure behavior by default is the way to go. IMO.
There are too many pitfalls in web application. We should try to mitigate
them
as many as possible where it could be done.
- Session functions never threw exceptions and making them throw
exceptions would break existing code, resulting in fatal errors. I don't
think it is a good idea to do such thing in a minor version. If we move
in next major to more widespread exception usage, it'd be fine but such
as it is now, exceptions would certainly not be expected coming from
session_start.
I agree with this. It may be delayed until PHP6.
Work round would be configurable exception/error or set ether negative or
very large value for regenerate_id_expire to disable this.
Current behavior is the same as "session.regenerate_id_expire=FOREVER"
We may set "session.regenerate_id_expire=300" or larger as default.
300 would be safe enough for under normal circumstance.
Although I think all user should handle the exception, it may require
code modification.
session.regenerate_id_exception=0 or 1
where 0 for 5.x, 1 for 6.x.
would be nice to have. User needs time to adopt exception. "Introducing this
now and enable by default later" seems better approach for users.
Thank you for point it out.
I'll add this to the RFC.
I'm also not sure what such exception would be useful for. So, say,
somebody accesses your site with stale session. You can not know if it
were an attack or just some user clicking an old link with a stale
cookie. You can not do anything with it but issue new session. So why
have that exception at all?
The exception is just a trigger for developers. Web application may have
history/list of sessions. Developer may ask user to check these, for
example.
This cannot be a session manager task, so developers must handle exception
for usable way.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi!
I'm recognizing reliability/availability as a part of security.
ISO 27000 defines it's a part of security.
Let's not parse semantics here. Declaring something that is not security
issue - i.e. would not lead to unauthorized access, data disclosure,
etc. - as security issue only makes real security issues drown in the
noise and not get proper priority. And mislead people into thinking that
existing ways - which are fine - are somehow insecure and make them not
use them.
Secure behavior by default is the way to go. IMO.
There are too many pitfalls in web application. We should try to
mitigate them
as many as possible where it could be done.
We're not implementing web application in the engine. It's the task for
the developers and libraries. Implementing something that can easily be
implemented in userspace in the core only makes it less flexible and
makes core more heavy to maintain. We're not really saving much code
there - in fact, we're adding more code as now the developer has to deal
with exceptions. If the session would be silently deleted, it would
probably be ok, even though still a narrow use case whcih I don't think
should be in the engine, but throwing hard errors doesn't look useful at
all.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi Stas,
On Thu, Mar 20, 2014 at 10:26 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
I'm recognizing reliability/availability as a part of security.
ISO 27000 defines it's a part of security.Let's not parse semantics here. Declaring something that is not security
issue - i.e. would not lead to unauthorized access, data disclosure,
etc. - as security issue only makes real security issues drown in the
noise and not get proper priority. And mislead people into thinking that
existing ways - which are fine - are somehow insecure and make them not
use them.
I'm OK with different name.
Lines between security issue or not is vague.
Session management is closely related to authentication/authorization.
Therefore,
I'm recognizing it as security issue, but it's not important. I agree that
discussion
wouldn't worth it.
Secure behavior by default is the way to go. IMO.
There are too many pitfalls in web application. We should try to
mitigate them
as many as possible where it could be done.We're not implementing web application in the engine. It's the task for
the developers and libraries. Implementing something that can easily be
implemented in userspace in the core only makes it less flexible and
makes core more heavy to maintain. We're not really saving much code
there - in fact, we're adding more code as now the developer has to deal
with exceptions. If the session would be silently deleted, it would
probably be ok, even though still a narrow use case whcih I don't think
should be in the engine, but throwing hard errors doesn't look useful at
all.
I'm looking for proper HTTP session management for session module.
Regenerating session ID is basic task of HTTP session management.
(I would like to discuss proper expiration also, but I'll leave it for now)
I'm proposing time stamp in $_SESSION because it does not require
overhead, complexity nor BC. If compatibility/availability would be an
issue, it can be implemented by another serializer and hide all time
stamps needed. Session module should support time stamps,
though.
I may propose serializer based solution also. It encapsulates time
stamps. There are number of implementations. Generic one that I
think of now is "serializer wrapper". It wraps current serializers to
have both user and system(session module) data. e.g. You can think
of this as array of serialized data.
What do you think about this?
Session manager should manage session properly rather than leaving
its tasks to users. IMHO.
I also use PHP for convenience and would like to concentrate what
is important for the objectives. I would rather rely on PHP feature for
basic things like session management/escaping/etc.
Let's make PHP do the basic job for web developers/applications.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
hi Yasuo,
I really appreciate your constant effort to improve security and php
in general. In the case of the session management I am not sure I can
vote positively on the current RFC(s).
Hi Stas,
On Thu, Mar 20, 2014 at 10:26 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
I'm recognizing reliability/availability as a part of security.
ISO 27000 defines it's a part of security.Let's not parse semantics here. Declaring something that is not security
issue - i.e. would not lead to unauthorized access, data disclosure,
etc. - as security issue only makes real security issues drown in the
noise and not get proper priority. And mislead people into thinking that
existing ways - which are fine - are somehow insecure and make them not
use them.I'm OK with different name.
Lines between security issue or not is vague.
I agree with Stas here. I have been asking for past CVEs related to
the possible issues you described here, I did not find any and sadly
did not get any information which could change my mind.
Most of what is described here should be covered by the application
layer as it really depends on what developers need. Per se, the
current session module is safe. It may not cover all edges cases but
this is why we have the necessary API to allow developers to add
behaviors, as desired (not necessary required, which is the point I
agree with Stas here).
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Hi Pieere,
Hi Stas,
On Thu, Mar 20, 2014 at 10:26 AM, Stas Malyshev <smalyshev@sugarcrm.com
wrote:I'm recognizing reliability/availability as a part of security.
ISO 27000 defines it's a part of security.Let's not parse semantics here. Declaring something that is not security
issue - i.e. would not lead to unauthorized access, data disclosure,
etc. - as security issue only makes real security issues drown in the
noise and not get proper priority. And mislead people into thinking that
existing ways - which are fine - are somehow insecure and make them not
use them.I'm OK with different name.
Lines between security issue or not is vague.I agree with Stas here. I have been asking for past CVEs related to
the possible issues you described here, I did not find any and sadly
did not get any information which could change my mind.Most of what is described here should be covered by the application
layer as it really depends on what developers need. Per se, the
current session module is safe. It may not cover all edges cases but
this is why we have the necessary API to allow developers to add
behaviors, as desired (not necessary required, which is the point I
agree with Stas here).
I think most PHP users are using session module as complete tool for their
web applications.
They rely on it for proper session management even if the manual explains
HTTP session
management cannot be trusted.
Since HTTP session management cannot be trusted, ID regeneration is
required to mitigate
risks. However, current session_regenerate_id() behavior can be called
optimum hardly.
It does not make sure obsolete session is deleted nor does not raise alarm
for possible
abuse. When it deletes old session, it is unreliable.
Attack methods/patterns for password clacking are evolving. Therefore,
password authentication
is evolving to multi-factor authentication due to raising risks. Password
hashing methods
are evolving due to technology/technique evolution. Session management
should evolve also.
There are tools like BackTrack and risk of session hijack is raising.
e.g. MITM is casual attack and real risk for web developers.
I would say current behavior was acceptable 10 years ago, but it would not
be
acceptable 10 years later for sure. I think we are in the middle of it.
HTTP session
management is center of web security and it would be the same next 10
years.
Hardening session management where it is possible worth the effort. IMHO.
I don't mind write document to help users to do proper HTTP session
management with
current session module. However, I would like to spend my time to make
session module
to manage session properly rather than spending time for document. It makes
sure
that all PHP users do precise session management unlike documentation.
Leaving active session behind is unacceptable risk to me.
I fail to understand why some of us do not see the risk of current HTTP
session
management and/or it should be part of user code.
Anyway, I don't want to write code that wouldn't be accepted.
I think "serializer wrapper" might be alternative choice. It works as
follows.
For serialization, serializer wrapper is called instead of serializer.
The wrapper accepts 2 hashes, 1 serializer as parameter. Hashes are
$_SESSION and internal data contains time stamps. It serializes both hashes
and return strings like
[HEADER: contains size of serialized data]+[serialized
$_SESSION]+[serialized internal data]
This returned string is passed to save handler.
When serializer wrapper is enabled, the wrapper is used instead of
serializer. Unserilize
does reverse operation of serialize. No internal data is exposed to users.
How about serializer wrapper?
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi,
I think most PHP users are using session module as complete tool for their
web applications.
They rely on it for proper session management even if the manual explains
HTTP session
management cannot be trusted.
You can't fix people's perceptions, and as Mateusz previously noted -
you're trying to fix a problem that appears in an upper layer, that
just isn't possible.
Since HTTP session management cannot be trusted, ID regeneration is
required to mitigate
risks. However, currentsession_regenerate_id()behavior can be called
optimum hardly.
It does not make sure obsolete session is deleted nor does not raise alarm
for possible
abuse. When it deletes old session, it is unreliable....
Leaving active session behind is unacceptable risk to me.
I fail to understand why some of us do not see the risk of current HTTP
session
management and/or it should be part of user code.
You keep repeating this argument that deleting the old session is
unreliable, not secure, unacceptable. That is simply not true.
Yes, it's a good practice to try to detect attacks and log them, etc.,
but it's not mandatory, not doing it is not insecure, not a risk, and
it is up to the application developer to decide whether or not to do
it and/or how to do it. There's no silver bullet for this.
How about serializer wrapper?
It's a different approach, but otherwise the same thing.
Cheers,
Andrey.
Hi!
Anyway, I don't want to write code that wouldn't be accepted.
I think "serializer wrapper" might be alternative choice. It works as
follows.
As a PECL extension that provides configurable serializer option - sure,
why not. As the part of the core - I don't see common enough use case.
If this extension proves popular and everybody would be using it, we can
merge it into core then.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi Stas,
On Fri, Mar 21, 2014 at 4:57 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Anyway, I don't want to write code that wouldn't be accepted.
I think "serializer wrapper" might be alternative choice. It works as
follows.As a PECL extension that provides configurable serializer option - sure,
why not. As the part of the core - I don't see common enough use case.
If this extension proves popular and everybody would be using it, we can
merge it into core then.
It requires session module modification. Session module should have flag to
enable/disable
serializer wrapper, should pass additional parameters, should maintain
internal state.
I guess you mean PECL session manager extension. It may be a good start.
This way, I don't have write number of RFCs and care about
misunderstandings like
"Trying to solve that is unsolvable", "Excluding XHR is solution", etc. For
precise/secure
session management, not only session_regenerate_id() but also expiration
handling, etc
should be handled more strictly to be secure than now.
Current session module does not manage session precisely/securely. This is
true since
users must write number of codes to manage session precisely. All of them
cannot be
performed by session manager. Example is how to handle exceptions. However,
most
of them can be done in session manager.
I choose session_regenerate_id() to discuss, since it is mandatory for
session security
and it is easy to understand what's wrong with it now. i.e. Which one is
secure
"Leave obsolete session indefinite period vs. Invalidate obsolete session
with certain period"
is clear to me. I think this is clear for you, too.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net