Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96154
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.175 as permitted sender)
To: internals@lists.php.net
References: <CAGa2bXaX1eZS=_Xg3JjCVZRBSruMy6yUk-PTrKoGOwW5Tg=0_Q@mail.gmail.com>
 <c90779f0-0034-b3fc-e2fe-e19503a196ce@gmail.com>
Message-ID: <327bf6ed-cd4a-dd4a-3d77-5a79e645d2d6@gmail.com>
Date: Mon, 26 Sep 2016 19:02:29 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <c90779f0-0034-b3fc-e2fe-e19503a196ce@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Fixing halfway implemented session management -
 timestamp based session management OR remove session_regenerate_id()
From: rowan.collins@gmail.com (Rowan Collins)

On 26/09/2016 07:02, Stanislav Malyshev wrote:
>> http://php.net/manual/en/session.security.php
>> >http://php.net/manual/en/function.session-regenerate-id.php
> It looks like those need some polishing. If somebody with native English
> volunteers it'd be great, otherwise I'll do it a bit later.

I was about to make the same comment. I'm sure there are some very 
important points in here, but it's quite hard to follow. For instance, 
the section "Non-Adaptive Session Management" jumps straight in with the 
claim that "PHP's session manager is adaptive by default", but never 
explains, as far as I can see, what that actually means. There's also 
far too many Warning and Note pop-outs on that page - the whole page is 
security advice, does it really make sense to colour every other 
paragraph pink?

I think a better approach for both the manual and RFCs proposing changes 
is to try to summarise the key attacks users need to protect against, 
and how to protect against them (as well as some of the trade-offs 
involved). Perhaps then an additional summary at the end with the 
recommended combination of settings. Use bullet points, summary 
sentences, etc.

I've probably got some details wrong here, but just as an example of the 
style:

Session Hijacking
===============

Session Hijacking is one of the simplest session-related attacks: an 
attacker accesses the website using another user's session. This can 
lead to problems such as:

- The attacker impersonating a known user.
- The attacker gaining access to restricted parts of a site.
- The attacker accessing the user's personal details stored on the 
server (e.g. a "My Account" or "My Orders" page)

To protect against session hijacking, you should:

- Restrict the places the session ID appears. For instance, set the 
session manager to use HTTP-only cookies, and no URL rewriting.
- Verify that the same user is accessing the session on each request. 
For instance, store "fingerprint" details such as User Agent and discard 
the session if it changes.
- ...

Session Fixation
==============

Session Fixation is similar to Session Hijacking, but rather than 
discovering the user's session ID, the attacker chooses a new session ID 
and tricks the application into using that session ID.

... and so on ...

Regards,

-- 
Rowan Collins
[IMSoP]