On Sat, Sep 28, 2013 at 6:47 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> Hi Leigh, > > On Fri, Sep 27, 2013 at 7:12 PM, 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. >> > > There are 2 improvements > > 1. Generally speaking, more frequent session ID regeneration is more > security. > This could make it more difficult for an attacker to take advantage, but then I would like to see other changes as well, for instance: a) Enable session.use_strict_mode by default. b) Enable session.use_only_cookies by default c) Enable session.cookie_httponly by default. d) Use a stronger session.hash_function with more session.hash_bits_per_character by default. e) Enable session.cookie_secure on secure connections (I know this is not going to be fool proof). There are probably more settings we could change to more security aware values. > 2. Detection/indication of attacks is good for security. > This is an interesting aspect; when an old session identifier is presented, from the end-user's perspective, either: a) They get redirected to the site's login page; the user gets redirected to the login page and unless they suspect their session was compromised (if that's indeed what happened), they will sign in again (the browser may have remembered the credentials, so it's a single click operation and they're back), or b) If the system uses a (naive) "remember me" feature, a new session gets created automatically and they don't notice a thing. >From the server-side's perspective, the cookie value could simply not be found, assuming that the regeneration also deletes the previous session data; there's no discernible difference between an old session and a compromised session afaict. This would be a different story if the session engine would keep track of past values as well. Btw, what I'm also missing from this proposal is the ability to hash against other factors, i.e. user agent. ISP's may use a transparent HTTP(s) proxy, most companies use an NAT, so being able to detect user agent changes may improve detection further. The bottom line is: if the system can make it easier to detect intrusion, it should be in the system and it should be easy :) > > Showing active sessions and possible intrusion/source of intrusion is > applications > task, but session ID regeneration upon IP change is easy and simple task > for > session module. Why not have it as optional feature? > > It would be better than nothing if end user has chance to know the attack. > IMHO. > > Many systems have notification mail when password or important information > have changed. Damage has already done if it is an attack, but user could > know > there were attack. Session ID regeneration is the same kind of counter > measure. > > If app supports number of active sessions, user could verify if they are > under > session hijack attack or not. It's up to app, though. > > Regards, > > -- > Yasuo Ohgaki > yohg...@ohgaki.net > -- -- Tjerk
