Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96167
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ohgaki.net designates 180.42.98.130 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <327bf6ed-cd4a-dd4a-3d77-5a79e645d2d6@gmail.com>
References: <CAGa2bXaX1eZS=_Xg3JjCVZRBSruMy6yUk-PTrKoGOwW5Tg=0_Q@mail.gmail.com>
 <c90779f0-0034-b3fc-e2fe-e19503a196ce@gmail.com> <327bf6ed-cd4a-dd4a-3d77-5a79e645d2d6@gmail.com>
Date: Tue, 27 Sep 2016 08:09:09 +0900
Message-ID: <CAGa2bXbmO67gdX+CDmbVOfVRKv7xemFoeWjWQPy_QZ18tdDVQg@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Fixing halfway implemented session management -
 timestamp based session management OR remove session_regenerate_id()
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi Rowan,

On Tue, Sep 27, 2016 at 3:02 AM, Rowan Collins <rowan.collins@gmail.com> wrote:
> 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 ...

Thank you.
I assumed that readers have basic web security knowledge, but I shouldn't.
I'll try to improve, but feel free to correct/improve it directly.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net