> Let's be clear here: this won't happen (in most cases), because the client > will simply get a new cookie and the session will keep working; it's like > what you would implement if your user level goes from anonymous to logged > in and vice versa.
I'm glad you addressed this because I'd been thinking that a lot of people were misinterpreting the common (non-hijacked) scenario, thinking that session regeneration meant a client-facing logout, which of course it doesn't as long as the client uses the new id on the next request. The concerns about forward and reverse proxies (you would typically use x-forwarded-for in the second case) seem also off-topic; even going through multiple proxies of each type won't matter as long as cache privacy is respected and the end user receives the new id. (One can argue that the more individual HTTP circuits you need to traverse, the more likely packets will be dropped, but that seems excessively paranoid for discussing this feature. I do agree with the server-side performance impact of very frequent changes on the forward proxy side forcing thrashing of the session store.) But the main problem, to me, is handling the aftermath of a hijack detected in this way. First, the UX factor: is it really feasible to provide the user with feedback like "You have been logged out for your protection because your session may have been hijacked by another user on your network -- now go find out which guy in the coffeeshop is listening!" That's quite a challenge. I'm sure many of us have seen the white hat studies of just how easy it is to get people to ignore warnings in the browser chrome or from runtimes like Java and Flash: look up the guy who got his office of "techie" Tor users to ignore redirects between https and http! I suppose if the victim accepts that something security-related has gone wrong, they don't have to understand what it was as long they can do something in response, and the most actionable advice is "You MUST leave this network immediately because it's insecure." But many people will ignore this message, and then (if I'm not misunderstanding the intent here) they will be prompted to log in again, on the same network. Problem: now the person who's still sniffing the network, who might have had only their session info before, can possibly sniff their username and hashed password, which is potentially much, much worse! (If a fresh login is over SSL but regular traffic is not, and the attacker was only using primitive sniffing of plaintext, that would be a mitigator.) Assuming a fresh login is not itself vulnerable, after authentication, do you offer (or force?) all other sessions linked to the user id to be expired? If so, this would of course include a legit session in another browser or device. In sum, I'm curious about the expected use of the feature _after_ the alert goes off. yohgaki? > Aha! I'm glad that you brought up mobile devices, because for those it's > more likely that in certain cases the updated cookie is not received while > the server believes that it was; scenario: "I stepped into an elevator and > was disconnected when I got out.". This makes it an unattractive option to > have enabled by default. Maybe the feature just needs to be disabled by default, yet not being able to protect against mobile session hijacking because of fear of lost responses seems like weakening it to the point of uselessness. I don't know the actual numbers, but I worry most about my users using their tablets in a coffeshop or hotel and if I had to turn this off for most mobile browsers, that would be a bit silly (AFAIK, there's not yet a universally-supported way of distinguishing wifi from mobile data, i.e. navigator.connection.type). We all accept that request-response cycles don't always complete on mobile, particularly on 3G, but I haven't yet seen anyone get metrics on how common it is based on network behavior _and_ user movement... also figuring that huge packet loss, once felt by the user, influences people to decide the network is effectively "down" and to not attempt any more requests for a while. It would make for an interesting study and forcibly changing a test cookie on every request (regardless of IP change) would be part of figuring out how bad the real-world situation is, at least for a given app and its users. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
