Hi Stas,
On Mon, Feb 1, 2016 at 8:44 AM, Stanislav Malyshev wrote:
>> Consequences
>> - If script executes session_commit()/session_destroy()/use read only
>> option, PHP will not perform GC. i.e. GC function is not called at
>> all. Therefore, probability of GC decreases and GC becomes less
>>
Hi!
> Consequences
> - If script executes session_commit()/session_destroy()/use read only
> option, PHP will not perform GC. i.e. GC function is not called at
> all. Therefore, probability of GC decreases and GC becomes less
> likely.
> - If script uses multiple session storage, only the last s
Hi!
On Wed, Jan 27, 2016 at 11:02 AM, Yasuo Ohgaki wrote:
>
> There are 2 ways to keep/generate stolen session
>
> - Set undeletable cookie to browser
> - Get active session via exploit and access it before GC
>
> As I have already explained, getting active session ID is trivial with
> access t
Hi Stas,
On Wed, Jan 27, 2016 at 10:25 AM, Stanislav Malyshev
wrote:
>
>> Other than HTTPS, setting unremovable cookies is easy with JavaScript
>> vulnerability. Currently, we only has session.use_strict_mode=1. This
>> is not good enough because attacker can generate valid session ID by
>
> That
Hi Stas,
On Wed, Jan 27, 2016 at 10:22 AM, Stanislav Malyshev
wrote:
>
>> Oops, sorry. Too many lines to reply, I misread
>> session_id()/session_create_id()
>>
>> session_id() sets session ID. Invalid char that cannot be accepted should be
>> rejected. Otherwise, user will have lost sessions wi
Hi!
> Other than HTTPS, setting unremovable cookies is easy with JavaScript
> vulnerability. Currently, we only has session.use_strict_mode=1. This
> is not good enough because attacker can generate valid session ID by
That sound unlikely, given how much space needs to be searched. By the
same ve
Hi!
> Oops, sorry. Too many lines to reply, I misread
> session_id()/session_create_id()
>
> session_id() sets session ID. Invalid char that cannot be accepted should be
> rejected. Otherwise, user will have lost sessions without errors.
As far as I know, handlers already reject characters that
Hi Stas,
On Wed, Jan 27, 2016 at 9:16 AM, Stanislav Malyshev wrote:
>>> About, since session_id() is a user function, what do we gain by
>>> limiting what it does?
>>
>> Prefix is a part of session ID and it should have the same requirement
>> as session ID for security reasons.
>
> I'm not sure
Hi Stas,
On Wed, Jan 27, 2016 at 9:12 AM, Stanislav Malyshev wrote:
>
>
>> CREATED is used to determine if the session should be renewed.
>> i.e. session_regenerate_id()
>
> This looks like something that belongs in userspace.
As my PHP like pseudo code illustrates, this could be done by user
sc
Hi Stas,
On Wed, Jan 27, 2016 at 8:49 AM, Stanislav Malyshev wrote:
>
>> I have
>> https://wiki.php.net/rfc/dbc2
>
> This doesn't seem to do anything with security. It's just a way of doing
> asserts, which we already have.
It's a framework for secure programming.
Using it is up to users, but Db
Hi!
>> About, since session_id() is a user function, what do we gain by
>> limiting what it does?
>
> Prefix is a part of session ID and it should have the same requirement
> as session ID for security reasons.
I'm not sure why you're talking about prefix. I thought that the issue
was that user
Hi!
> CREATED is used to determine if the session should be renewed.
> i.e. session_regenerate_id()
This looks like something that belongs in userspace.
> UPDATED is used to determine if the session is expired or not.
> "UPDATED+ttl < now" is expired.
We already have GC mechanism that does that
Hi!
> I have
> https://wiki.php.net/rfc/dbc2
This doesn't seem to do anything with security. It's just a way of doing
asserts, which we already have.
> https://wiki.php.net/rfc/secure_serialization
This may be a viable extension of somebody really is going to use it. I
would suggest making a PE
Hi Dan,
On Wed, Jan 27, 2016 at 12:05 AM, Dan Ackroyd wrote:
>> I'll appreciate if one could find defect if there is.
>
> The problem is that you're trying to build on a foundation of sand.
> The session handling works but is incredibly fragile.
>
> Or to put it more colloquially this is a "how t
On 26 January 2016 at 12:17, Yasuo Ohgaki wrote:
> I'll appreciate if one could find defect if there is.
The problem is that you're trying to build on a foundation of sand.
The session handling works but is incredibly fragile.
Or to put it more colloquially this is a "how to get to Dublin
probl
Hi Stas,
On Tue, Jan 26, 2016 at 7:28 PM, Yasuo Ohgaki wrote:
> I've already have/will have 3 RFC for session.
> This one, session_id() and user space serialize handler.
> https://github.com/php/php-src/pull/1732
> I would like not to have too many RFCs for session.
I would like to make PHP more
Hi Stas,
TL;DR; for others.
Those who have no idea why this RFC is mandatory and how current
session management is broken, please read the RFC's TL;DR;.
On Tue, Jan 26, 2016 at 5:01 PM, Stanislav Malyshev wrote:
>> https://wiki.php.net/rfc/precise_session_management
>> https://github.com/php/php
Hi Stas,
On Tue, Jan 26, 2016 at 5:15 PM, Stanislav Malyshev wrote:
>> Since this RFC is about preciseness of session management, I would like to
>> change session_id() validates against default allowed chars as follows.
>> (As well as enabling already written session_create_id() function)
>> Thi
Hi!
> Since this RFC is about preciseness of session management, I would like to
> change session_id() validates against default allowed chars as follows.
> (As well as enabling already written session_create_id() function)
> This patch is against the PR.
I would strongly advise not to add more t
Hi!
> https://wiki.php.net/rfc/precise_session_management
> https://github.com/php/php-src/pull/1734
I'm re-reading this RFC and I notice it does quite a lot of things:
- Add five new INI values
- Add two new functions
- Changes behavior of two widely used functions
- Changes four different defau
Hi Dan,
On Fri, Jan 8, 2016 at 12:54 AM, Dan Ackroyd wrote:
>
> I find it hard to give feedback on this RFC as I cannot understand
> what it is saying.
>
> In an RFC, defining behaviour just through example like this:
>
>> Obsolete session data has NEW_SID and TTL upto session.ttl_destroy.
>>
>>
Hi Yasuo,
I find it hard to give feedback on this RFC as I cannot understand
what it is saying.
In an RFC, defining behaviour just through example like this:
> Obsolete session data has NEW_SID and TTL upto session.ttl_destroy.
>
> $_SESSION['__PHP_SESSION__']['NEW_SID'] = ;
> $_SESSION['__P
Hi Mike,
On Mon, Dec 21, 2015 at 1:24 PM, Mike Willbanks wrote:
>
> On Sun, Dec 20, 2015 at 7:01 PM, Yasuo Ohgaki wrote:
>>
>> Hi all,
>>
>> On Sat, Dec 19, 2015 at 7:33 AM, Yasuo Ohgaki wrote:
>> > I would like to restart better session management for PHP 7.1.
>> >
>> > https://wiki.php.net/rf
Hello Yasuo,
On Sun, Dec 20, 2015 at 7:01 PM, Yasuo Ohgaki wrote:
> Hi all,
>
> On Sat, Dec 19, 2015 at 7:33 AM, Yasuo Ohgaki wrote:
> > I would like to restart better session management for PHP 7.1.
> >
> > https://wiki.php.net/rfc/precise_session_management
> >
> > Although this RFC targets P
24 matches
Mail list logo
