Hi,
On Fri, Sep 27, 2013 at 6:54 PM, Leigh <lei...@gmail.com> wrote: > On 27 September 2013 11:39, Peter Lind <peter.e.l...@gmail.com> wrote: > > On 27 September 2013 12:12, Leigh <lei...@gmail.com> wrote: > >> > >> So on a successful session hijack (correct SID, new IP) the attacker > >> gets a new SID and keeps the valid session while the legitimate user > >> gets kicked out. > >> > >> Not seeing how that improves things at all. > > > > In your scenario, user gets booted and thus knows somethings wrong. Much > > better than the attacker hijacking the session without the user knowing > > anything at all. > > > > Regards > > Peter > > And what is done to invalidate the session now gained by the attacker? > Since this is a proposal to handle such things internally. > Do you really think random user X will think something is wrong beyond > the site they were using just kicking them out for no reason? So now > what do they do now? Log in again? The attacker still has the > previously valid session, so nothing is gained. > Yes, much more is required to actually provide tangible benefits in terms of security. The site would have to keep track of the last five invalidated session identifiers and if any of those is presented, it would delete all sessions for that user. The core can practically only do a fraction of that for you, so I would agree that on the whole, this patch would not lead to a secure-by-default sessions implementation. > This is exactly why this kind of logic belongs as user code. We're > starting to define rules for a system that should be agnostic to how > it is being used. > -- -- Tjerk
