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