Re: [RFC] [Discussion] Secure session_regenerate_id()
Hi Stas,
On Thu, Mar 20, 2014 at 3:35 AM, Stas Malyshev <[email protected]>wrote:
> > Secure session_regenerate_id()
> > https://wiki.php.net/rfc/session_regenerate_id
>
> Reading this RFC, I have the following thoughts:
>
> 1. 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.
2. 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.
3. 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
[email protected]
Thread (23 messages)