Hi Rowan,

On Tue, Sep 27, 2016 at 3:02 AM, Rowan Collins <rowan.coll...@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
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to