Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
On Mon, Sep 30, 2013 at 4:51 PM, Tjerk Meesters tjerk.meest...@gmail.comwrote: 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. I was thinking propose RFC some of these changes. 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 :) I agree. We can do many more things to make session more secure. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
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
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
On Sat, Sep 28, 2013 at 2:07 PM, Sanford Whiteman swhitemanlistens-softw...@cypressintegrated.com wrote: ... ESPECIALLY since userland implementation is so trivial. I do not see any new argument in this discussion since a couple of days. If desired, I would suggest to create a RFC (should have been done already :) and move to the next steps. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
You guys are missing the point. This isn't a language level issue. I can imagine some sort of package or a library being made, some sort of wrapper around the current session commands, perhaps integrated into some sort of extension. But it is NOT a language level issue. This isn't a problem the language needs to solve, ESPECIALLY since userland implementation is so trivial. The core of the problem is education, not lack of tools by the side of the language. And that's where the focus should be. How do we do it? I don't know. Blog posts? PHP manual? Conferences? Maybe. But I still don't think this is a problem that language should solve. On Sat, Sep 28, 2013 at 1: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. 2. Detection/indication of attacks is good for security. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
On 28 September 2013 11:27, Madara Uchiha mad...@tchizik.com wrote: You guys are missing the point. This isn't a language level issue. I can imagine some sort of package or a library being made, some sort of wrapper around the current session commands, perhaps integrated into some sort of extension. But it is NOT a language level issue. This isn't a problem the language needs to solve, ESPECIALLY since userland implementation is so trivial. I would disagree. PHP has very low security levels by default and some WTF security issues because of default settings. It should be the other way round: high security by default that you need to actively change if you want it lowered. The problem is that the majority of PHP developers for better or worse think they can copypaste solutions to problems and forget about things after that as long as the output on their screens look ok. For many developers, security is an afterthought if even that. And you are, quite simply, NOT GOING TO CHANGE THAT IN THE FORESEEABLE FUTURE. It's not a question of whether you're right or wrong in principle - it's a simple question of statistics. You will have close to zero impact on the PHP developers, no matter how many blog articles you write. It is too large and too diverse a group. So you're stuck with two choices: accept that PHP security is lax and that as a result a lot of code will have many attack vectors, or try to change the language itself for the better. The third option of educate is a mirage. Note: I'm not saying this feature would be an overall benefit for the security of PHP, but the reasoning behind it is right. Regards Peter -- hype WWW: plphp.dk / plind.dk CV: careers.stackoverflow.com/peterlind LinkedIn: plind Twitter: kafe15 /hype
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
On Sep 28, 2013 10:39 AM, Peter Lind peter.e.l...@gmail.com wrote: So you're stuck with two choices: accept that PHP security is lax and that as a result a lot of code will have many attack vectors, or try to change the language itself for the better. The third option of educate is a mirage. PHP provides you with all the tools you need to write secure apps. I could go around writing mysql_query($_REQUEST[blah]) but I don't. Why? Because I have been educated. We don't have restrictions in the core that prevent me from doing it, and we don't need them either. I agree with you, being secure by default is a worthy objective, but the proposal here shouldn't even be on by default. (remember not everyone is able to control their ini settings and whatnot) Education is not a mirage. People picked up their insecure coding habits from somewhere, and if its from laziness then I don't think they really deserve protecting. If it was from a terrible blog article promoting insecure practices then we need better articles. There's not much we can do to remove the content that's already out there, but there's a lot we can do with providing new, up to date and accurate content.
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
On 28 September 2013 12:25, Leigh lei...@gmail.com wrote: On Sep 28, 2013 10:39 AM, Peter Lind peter.e.l...@gmail.com wrote: So you're stuck with two choices: accept that PHP security is lax and that as a result a lot of code will have many attack vectors, or try to change the language itself for the better. The third option of educate is a mirage. PHP provides you with all the tools you need to write secure apps. I could go around writing mysql_query($_REQUEST[blah]) but I don't. Why? Because I have been educated. We don't have restrictions in the core that prevent me from doing it, and we don't need them either. Care to back that up with an argument? I agree with you, being secure by default is a worthy objective, but the proposal here shouldn't even be on by default. (remember not everyone is able to control their ini settings and whatnot) Worthy objective? You just stated your opinion that you don't want default protection in the core language. Which is it? Education is not a mirage. People picked up their insecure coding habits from somewhere, and if its from laziness then I don't think they really deserve protecting. If it was from a terrible blog article promoting insecure practices then we need better articles. There's not much we can do to remove the content that's already out there, but there's a lot we can do with providing new, up to date and accurate content. How many years have PHP been around? For how long have we been trying to educate people to avoid mysql_* functions? Has it worked? No. You can educate a fair amount of people but when you have the userbase of PHP it's downright stupid to think you'll get the majority on board. Also, saying that people deserve what they get because they're not educated developers, is being arrogant. -- hype WWW: plphp.dk / plind.dk CV: careers.stackoverflow.com/peterlind LinkedIn: plind Twitter: kafe15 /hype
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
... ESPECIALLY since userland implementation is so trivial. Trivial for most users means copy-paste an unmaintained class library you found somewhere so you haven't solved the problem. Unless something comes from one of the few trusted security extensions or from a top framework, it's doubtful it'll be thoroughly reviewed and/or correctly implemented. I think security measures belong in the preprocessor if possible. If they are known to be useful, yet rejected only because they're trivial -- despite not being commonly available to the majority of PHP developers -- you are failing the community. On the other hand, if they are known to be useful, yet rejected because they're complex, requiring too many config options, new classes/functions, core documentation, AND user education to write companion logic in userland then I think that's better reasoning. And that's *clearly* the case here. This is not a simple implementation; it requires flexible control from userland and some delicate app logic to interact with the user, and the language can't do the last part AFAICS. As sketched out so far, it is outright harmful. I could publish a post now about the vulnerability it creates, where sniffing a session allows you to force an elevated login, from which you can sniff credentials. (Maybe my first vuln note was tl;dr but please consider this.) The core of the problem is education, not lack of tools by the side of the language. And that's where the focus should be. How do we do it? I don't know. Blog posts? PHP manual? Conferences? Maybe. The first round of objections showed that senior developers *on Internals* didn't understand how PHP session regeneration works! How do you solve that? If the language offered features like this in the first place, PHP users would have known about for years. The fact that it wasn't grokked here reveals that no matter how trivial' it seems, most people aren't doing it (as yohgaki noted) and not because they understand the consequences, they just don't get it at all. Again, if it were simple to implement and didn't have unintended security consequences of its own, the fact that the sharpest users don't totally get it would *prove* that it should be left to the internals team. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
On 26 September 2013 11:32, Tjerk Meesters tjerk.meest...@gmail.com wrote: On Thu, Sep 26, 2013 at 6:19 PM, Leigh lei...@gmail.com wrote: There's several scenarios where a users IP changes and you don't want to drop their session. (That doesn't mean it should simply have an option to disable it either) 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. Right, so maybe I misunderstood the intent of this. I was reading it as: valid SID on new IP = drop session, which to me seems like the more secure approach. What you're saying is is when a valid SID is supplied on a new IP, you regenerate the SID and the session continues to be valid on the new IP? 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
Am 27.09.13 12:12, schrieb Leigh: On 26 September 2013 11:32, Tjerk Meesters tjerk.meest...@gmail.com wrote: On Thu, Sep 26, 2013 at 6:19 PM, Leigh lei...@gmail.com wrote: There's several scenarios where a users IP changes and you don't want to drop their session. (That doesn't mean it should simply have an option to disable it either) 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. Right, so maybe I misunderstood the intent of this. I was reading it as: valid SID on new IP = drop session, which to me seems like the more secure approach. What you're saying is is when a valid SID is supplied on a new IP, you regenerate the SID and the session continues to be valid on the new IP? 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. So what about an ISP that changes the IP-Adress of it's clients every half hour? Suddenly the IP for a valid SID has changed and the legitimate user gets kicked out. Every half hour. No Attacker needed. Does that improve things? Regards Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5 E 08°23'58 | | http://andreas.heigl.org http://hei.gl/wiFKy7 | +-+ | http://hei.gl/root-ca | +-+ smime.p7s Description: S/MIME Kryptografische Unterschrift
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
On 27 September 2013 12:12, Leigh lei...@gmail.com wrote: On 26 September 2013 11:32, Tjerk Meesters tjerk.meest...@gmail.com wrote: On Thu, Sep 26, 2013 at 6:19 PM, Leigh lei...@gmail.com wrote: There's several scenarios where a users IP changes and you don't want to drop their session. (That doesn't mean it should simply have an option to disable it either) 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. Right, so maybe I misunderstood the intent of this. I was reading it as: valid SID on new IP = drop session, which to me seems like the more secure approach. What you're saying is is when a valid SID is supplied on a new IP, you regenerate the SID and the session continues to be valid on the new IP? 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php 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 -- hype WWW: plphp.dk / plind.dk CV: careers.stackoverflow.com/peterlind LinkedIn: plind Twitter: kafe15 /hype
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
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. 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
On 27 September 2013 12:54, 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. And what is done when the user thinks everything is fine and dandy? My point was that the scenario you created did not pose a problem - if anything it would be a benefit (as you actually *can* detect some problems now). 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. That's for the userland code to decide. 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. I would agree. I was just pointing out that your example was not in fact much of an argument against the proposal. Regards Peter -- hype WWW: plphp.dk / plind.dk CV: careers.stackoverflow.com/peterlind LinkedIn: plind Twitter: kafe15 /hype
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
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
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
On Tue, Sep 24, 2013 at 4:29 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, There isn't any good counter measure session hijack. However, we can regenerate session ID if IP address has changed. Hijacked users might notice that they have been logged out if session ID is regenerated by attackers. Therefore, users have slight chance to notice that they were under attack. It's not greatly effective, but better than nothing. Although this can be implemented in user script, it would be better if session module supports this behavior. Better security by default is good thing. It requires INI, since some apps may assume session ID would not change. (I do not encourage to use session ID for CSRF protection, but there are such implementations, for example.) A concern is that there are growing number of browsers share state. I do not research these browsers behavior yet. I suppose session cookie (expire=0) would not be shared. Anyone has any comments on this? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net 1, as you said this regeneration is not feasible for everyone: in some setups the client remote address not available to php, or through another environment variable, in other cases the client uses some kind of proxy or tunnel (tor comes to mind) which causes the source ip to change between requests, and there are also some ISPs who are doing stuff like agressive NATing or giving out public IPs through DHCP but with really short lease times, so the clients are changing IPs frequently. 2, this can be implemented in userland, either in the application bootstrap, or writing a custom session handler( http://php.net/manual/en/class.sessionhandler.php). 3, it seems that there is an agreement that introducing language level INI switches are a bad thing. if we add this, frameworks/apps/etc. which don't want this feature (because they don't need it, or they have a better implementation already) would be in a bad spot, because they would either write some code to detect and circumwent this, or they would have to educate their users to disable this feature in their installation, which can be a hard thing to do, as many sites are running on shared hosts, where doing configuration changes are hard even more when you are requesting to disable a security feature. so to summarize: personally I'm not convinced that this would be useful for most of the php users, as client IPs changing to frequently to be not cumbersome for the users to lose their sessions, but this could definitely break some sites on the internet (php installations behind proxies/load balancers not passing the original client in in REMOTE_ADDR), and this would also require countermeasures from the framework/apps/etc. which makes me vote a -1 on this proposed feature. maybe this could be shipped as a non-default SessionHandler implementation, and reuse the current session handler infrastructure and config ini. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
On Sep 24, 2013 3:43 AM, Laruence larue...@php.net wrote: I don't think this is language concerning issue. it could be done in user script.. thanks I agree entirely with Laurence (and others). This shouldn't be a core feature. It's not one size fits all. There's several scenarios where a users IP changes and you don't want to drop their session. (That doesn't mean it should simply have an option to disable it either) Many people still have dynamic IP addresses for their home connections, but the group who would suffer the most would be mobile users. It's pretty frustrating to use most sites with a phone as it is, without being kicked off every time you switch between grps or hsdpa or whatever.
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
Hi, On Thu, Sep 26, 2013 at 6:19 PM, Leigh lei...@gmail.com wrote: On Sep 24, 2013 3:43 AM, Laruence larue...@php.net wrote: I don't think this is language concerning issue. it could be done in user script.. thanks I agree entirely with Laurence (and others). This shouldn't be a core feature. It's not one size fits all. There's several scenarios where a users IP changes and you don't want to drop their session. (That doesn't mean it should simply have an option to disable it either) 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. Many people still have dynamic IP addresses for their home connections, but the group who would suffer the most would be mobile users. It's pretty frustrating to use most sites with a phone as it is, without being kicked off every time you switch between grps or hsdpa or whatever. 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. -- -- Tjerk
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
Hi Tjerk, On Thu, Sep 26, 2013 at 7:32 PM, Tjerk Meesters tjerk.meest...@gmail.comwrote: Many people still have dynamic IP addresses for their home connections, but the group who would suffer the most would be mobile users. It's pretty frustrating to use most sites with a phone as it is, without being kicked off every time you switch between grps or hsdpa or whatever. 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. When IP packets are lost, clients may not receive new session ID. This may occur when packets are lost while server is trying to set new session ID cookie. Unless users have really bad connections, this happens unlikely. Users who are concerned for this situation should disable it. Users who are concerned security should accept this case. The motivation of the feature is to encourage secure session management to users, not to cover all situations perfectly. Changing session ID on events is best practice of security. Failures in rare cases would not make it bad practice. This feature cannot be enabled by default, since HTTP header that indicates client IP may vary. Anyway, how many of us follows session ID management security best practice? - login - logout - re-authentication (e.g. Require password to change sensitive info) - timeout (Long living session ID should be renewed) - IP change (This could be hijacked session) - else? Regenerating session ID at login is mandatory, so I suppose everyone do. (If not, you must.) Generally speaking, if session ID changes more frequently, hijack attack become more difficult. Even if session ID is the center of the web security, it is fragile. Therefore, it should be as secure as possible whenever it can. IMHO. Regards, P.S. As I wrote previous mail, I'll start from documentation. Even if I made patch, it would be an optional feature anyway. -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
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
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
Users who are concerned for this situation should disable it. Users who are concerned security should accept this case. I assume users are as we understand them here, i.e. me. But as a developer-user I would likely want to empower my end-users to turn off this feature themselves. With high-volume sites (not that I really have any anymore, but a guy can dream) there isn't going to be a one-size-fits-all regarding connection quality, but there can be a default INI setting and then a function that we can call to override it. Paranoid users will turn/leave it on any user in a sketchy connection situation will turn it off (per session or for all their future sessions). Which is kind of why this is sounding more and more like a nice discussion... about a userland solution. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
Hi Sanford, On Fri, Sep 27, 2013 at 7:57 AM, Sanford Whiteman swhitemanlistens-softw...@cypressintegrated.com wrote: Users who are concerned for this situation should disable it. Users who are concerned security should accept this case. I assume users are as we understand them here, i.e. me. But as a developer-user I would likely want to empower my end-users to turn off this feature themselves. With high-volume sites (not that I really have any anymore, but a guy can dream) there isn't going to be a one-size-fits-all regarding connection quality, but there can be a default INI setting and then a function that we can call to override it. Paranoid users will turn/leave it on any user in a sketchy connection situation will turn it off (per session or for all their future sessions). Which is kind of why this is sounding more and more like a nice discussion... about a userland solution. Besides the issue with unstable connection, we have URL based session. When URL based session is used, this feature should be disabled as pages are cached by browsers. Even if this change is made, it would not be a default and there would be INI for client IP header or variable. So no need to worry for being default. (Did I missed not for not a default in previous mails? If I did, my apologies.) BTW, if connection is unstable and an app force user to logout, is it going to be a problem? It would depend on message displayed, but I guess users think it is due to unstable connection. If mobile apps are native, almost all apps store username/password or some credential that automatically reconnect to service. Therefore, I suppose it wouldn't become issue. I might be too optimistic, though. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
When URL based session is used, this feature should be disabled as pages are cached by browsers. OK, I suppose, but that seems to be an edgier case than what we're already discussing. BTW, if connection is unstable and an app force user to logout, is it going to be a problem? It would depend on message displayed, but I guess users think it is due to unstable connection. I definitely (!!!) would not think that if an app forced me to log in again that it had to do with my connection quality unless I had already decided the connection was practically unusable -- and that all bets were off as to whether anything would work as expected. Even if I intuited the reason and/or was told about it, I would not accept being logged out of an app because I went into an elevator (to use Tjerk's point) or through a train tunnel as appropriate. At all. You're basically adding insult to injury: not only do you have a bad connection, but you need to always log in. Makes for a very, very bad user experience. I would hate an app that did that to me... if I encountered the situation. And what I was interrogating is _how common_ such a situation would be in each developer's real world, predicting it would be different based on the ecosystem of a particular app + its users. For example, my main app is too heavy for most people to use over 3G connections, period, so they are unlikely to run into the problem with us because they wouldn't be trying to use the site in the first place. Other apps have a lightweight version that is otherwise usable over slow/sporadic connections and thus its users are more likely to encounter timeouts, which the app has previously been tolerating. This why I referred to _the end-user_ (not _PHP users_) being able to turn such a feature off. Only a site that is 100% sure that it only is useable over WiFi/WAN/LAN should roll out such a feature without giving users control, because otherwise you are _ensuring_ your site won't work on 3G! Why would you do that if it used to work? If mobile apps are native, almost all apps store username/password or some credential that automatically reconnect to service. Native apps can have different levels of resilience -- we MUST consider sites that just happen to be accessed from mobile. And in those cases there can't be any question that being logged out because you didn't receive the updated id is not acceptable. The question is only _how often_ you are pissing off users, not _whether_ you will piss off a user when you do this. I also want to know how you deal with the other insult-to-injury that I mentioned, where logging out someone after a _real_ session hijack then reveals their credentials to the attacker who's still listening on the same network. I'm starting to think there are unintended consequences here that are approaching considered harmful levels. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
Hi Standord, On Fri, Sep 27, 2013 at 9:45 AM, Sanford Whiteman swhitemanlistens-softw...@cypressintegrated.com wrote: When URL based session is used, this feature should be disabled as pages are cached by browsers. OK, I suppose, but that seems to be an edgier case than what we're already discussing. BTW, if connection is unstable and an app force user to logout, is it going to be a problem? It would depend on message displayed, but I guess users think it is due to unstable connection. I definitely (!!!) would not think that if an app forced me to log in again that it had to do with my connection quality unless I had already decided the connection was practically unusable -- and that all bets were off as to whether anything would work as expected. Even if I intuited the reason and/or was told about it, I would not accept being logged out of an app because I went into an elevator (to use Tjerk's point) or through a train tunnel as appropriate. At all. You're basically adding insult to injury: not only do you have a bad connection, but you need to always log in. Makes for a very, very bad user experience. I would hate an app that did that to me... if I encountered the situation. And what I was interrogating is _how common_ such a situation would be in each developer's real world, predicting it would be different based on the ecosystem of a particular app + its users. For example, my main app is too heavy for most people to use over 3G connections, period, so they are unlikely to run into the problem with us because they wouldn't be trying to use the site in the first place. Other apps have a lightweight version that is otherwise usable over slow/sporadic connections and thus its users are more likely to encounter timeouts, which the app has previously been tolerating. This why I referred to _the end-user_ (not _PHP users_) being able to turn such a feature off. Only a site that is 100% sure that it only is useable over WiFi/WAN/LAN should roll out such a feature without giving users control, because otherwise you are _ensuring_ your site won't work on 3G! Why would you do that if it used to work? If mobile apps are native, almost all apps store username/password or some credential that automatically reconnect to service. Native apps can have different levels of resilience -- we MUST consider sites that just happen to be accessed from mobile. And in those cases there can't be any question that being logged out because you didn't receive the updated id is not acceptable. The question is only _how often_ you are pissing off users, not _whether_ you will piss off a user when you do this. I also want to know how you deal with the other insult-to-injury that I mentioned, where logging out someone after a _real_ session hijack then reveals their credentials to the attacker who's still listening on the same network. I'm starting to think there are unintended consequences here that are approaching considered harmful levels. I also don't want to disturb end-users too much. The reason why I think unstable connection would not be much problem is lost session ID occurs only when end-users are connected to site _and_ the connection is immediately lost before setting new session ID. Under normal circumstances, entering elevator or tunnel would not loose session ID most likely since lost connection would not loose session ID. When end-users simply lost their connection, IP address wouldn't change. Therefore, session ID wouldn't change. Establishing connection and immediately loosing it might cause lost session ID. To loose session ID, end-users have to send request to server and loose connection _before_ they receive new session ID. I'm supposing this happens most unlikely. I might be too optimistic, though. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
Under normal circumstances, entering elevator or tunnel would not loose session ID most likely since lost connection would not loose session ID. When end-users simply lost their connection, IP address wouldn't change. There's good reason to believe that the event of being assigned a new IP from a forward proxy farm will be triggered by the event of dropping and reconnecting to the mobile network repeatedly. So, in general, if ever there were a time to be sensitive to preserving sessions, it's when someone has a sporadic connection. I might be too pessimistic... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
Why couldn't this be implemented on userland again? I don't feel this is a language level issue. On Wed, Sep 25, 2013 at 8:55 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Mike, On Wed, Sep 25, 2013 at 2:16 PM, Mike Willbanks pen...@gmail.com wrote: Each and every type of prevention measure has consequences and not only that but MAJOR consequences. If you are detecting IP changes you rule out most if not all major proxy networks that exist. While not first of mind; when handling this you can easily remove the old session without properly transitioning to the new. This is an option based off of individual application vs. a language option or construct. There are a ton of different measures that you might take based off of changes to the end user data. I think this would be a poor idea in the long run due to the consequences that you may incur. The more I get this kind of response, the more I feel we should introduce this feature as session module optional feature. Regenerating session ID should not be any problem as long as session ID is cookie based, save handler lock session data while it is used. As far as I know, the only faulty save handler is mm save handler. (I would like to implement lock in mm, but it's low priority for me. When TranSID is enabled, it would cause problems due to cached pages.) The best practice of the session ID management is regenerating session ID when events happen. Mandatory one is login event. Web programmers must regenerate session ID to make sure session safety at login. IP address change is one of the event, even though it's not mandatory. There is PHP framework called Piece Framework that has option regenerate session ID for every request to achieve maximum session ID security, for example. If regeneration of session ID causes misbehavior, then it is a bug including users fault. I think if I disable this feature when TranSID on and/or expire is not 0, then there would not be issues. Unless web programmers use session ID for CSRF protection, etc. Anyway, I'll start from documentation. If there are any comments, I'll appreciate it. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
Hi Madara,
On Thu, Sep 26, 2013 at 7:49 AM, Madara Uchiha mad...@tchizik.com wrote:
Why couldn't this be implemented on userland again? I don't feel this
is a language level issue.
PHP is not only language, but also meta framework.
It is better to think as how framework support session. IMHO.
I suppose there aren't many PHP frameworks that implement
session manager by itself.
Any users may implement this by themselves. It's not difficult.
session_start()
if ($_SESSION['IP'] !== $CLIENT_IP) {
// $CLIENT_IP depends on configuration
$_SESSION['IP'] = $CLIENT_IP;
session_regenerate_id(true);
}
The motivation is not make things easier, but to encourage users
use more secure session management. Session ID must be regenerated
when event happens, e.g. login. Session ID should be regenerated
periodically to reduce hijack risk, too. Users should regenerate session
ID anyway. Why not support should/must be done operations?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
Hi, On Tue, Sep 24, 2013 at 12:46 PM, Ronald Chmara rona...@gmail.com wrote: When you have a group of front-end termination points in a pool, proxying requests off to hundreds of machines for thousands of applications, tying a session to any IP is a headache. IMO, sessions are supposed to be tied to users, not any given inbound IP that can, and may, jump between different routers, proxies, NAT hosts, etc. Session is tied to specific user(browser) regardless of IP unless session ID is hijacked. Renewing session ID does not matter. Regenerating session ID when IP has changed would help users to notice session hijack. This is the sole purpose of regenerating session ID when IP has changed. I think only few apps do this now. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
Hi Laruence, On Tue, Sep 24, 2013 at 11:42 AM, Laruence larue...@php.net wrote: I don't think this is language concerning issue. it could be done in user script.. Session should be managed as secure as possible. We can promote better session management in document. It's an option. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
On Mon, Sep 23, 2013 at 7:29 PM, Yasuo Ohgaki wrote: Hi all, There isn't any good counter measure session hijack. However, we can regenerate session ID if IP address has changed. Hijacked users might notice that they have been logged out if session ID is regenerated by attackers. Therefore, users have slight chance to notice that they were under attack. It's not greatly effective, but better than nothing. Although this can be implemented in user script, it would be better if session module supports this behavior. Better security by default is good thing. It requires INI, since some apps may assume session ID would not change. (I do not encourage to use session ID for CSRF protection, but there are such implementations, for example.) A concern is that there are growing number of browsers share state. I do not research these browsers behavior yet. I suppose session cookie (expire=0) would not be shared. Anyone has any comments on this? Each and every type of prevention measure has consequences and not only that but MAJOR consequences. If you are detecting IP changes you rule out most if not all major proxy networks that exist. While not first of mind; when handling this you can easily remove the old session without properly transitioning to the new. This is an option based off of individual application vs. a language option or construct. There are a ton of different measures that you might take based off of changes to the end user data. I think this would be a poor idea in the long run due to the consequences that you may incur.
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
On Tue, Sep 24, 2013 at 8:52 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi, On Tue, Sep 24, 2013 at 12:46 PM, Ronald Chmara rona...@gmail.com wrote: When you have a group of front-end termination points in a pool, proxying requests off to hundreds of machines for thousands of applications, tying a session to any IP is a headache. IMO, sessions are supposed to be tied to users, not any given inbound IP that can, and may, jump between different routers, proxies, NAT hosts, etc. Session is tied to specific user(browser) regardless of IP unless session ID is hijacked. Renewing session ID does not matter. Regenerating session ID when IP has changed would help users to notice session hijack. This is the sole purpose of regenerating session ID when IP has changed. I think only few apps do this now. So, say you have many front ends, with load balancing, and public IP addresses. Those front-ends talk on private IP ranges to back-end machines, so the session can come in from any public IP, be proxied, and handed off. This, BTW, is not hypothetical, it's about my work with http://appfog.com. Some actual numbers to explain : Our Singapore location (for example) has 29,088 websites, with 6 incoming IP addresses talking to 27 website nodes. Regenerating session keys is a waste of CPU at that scale, as a given user's requests may jump around 6 different inbound addresses, and any number of servers. Takeaway: 1) Binding session to IP doesn't work at scale. 2) Seeing that the IP has changed is totally useless to detect hijacking. 3) Session libraries that are expecting state, on the internet, are fundamentally broken by design. rant There is no such thing as a secure http session. Ever. The protocol, by design, does not allow it. Ever. You can add layers (such as https) to make things better, but if you want secure communication, don't use the internet. /rant -Ronabop
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
Hi Mike, On Wed, Sep 25, 2013 at 2:16 PM, Mike Willbanks pen...@gmail.com wrote: Each and every type of prevention measure has consequences and not only that but MAJOR consequences. If you are detecting IP changes you rule out most if not all major proxy networks that exist. While not first of mind; when handling this you can easily remove the old session without properly transitioning to the new. This is an option based off of individual application vs. a language option or construct. There are a ton of different measures that you might take based off of changes to the end user data. I think this would be a poor idea in the long run due to the consequences that you may incur. The more I get this kind of response, the more I feel we should introduce this feature as session module optional feature. Regenerating session ID should not be any problem as long as session ID is cookie based, save handler lock session data while it is used. As far as I know, the only faulty save handler is mm save handler. (I would like to implement lock in mm, but it's low priority for me. When TranSID is enabled, it would cause problems due to cached pages.) The best practice of the session ID management is regenerating session ID when events happen. Mandatory one is login event. Web programmers must regenerate session ID to make sure session safety at login. IP address change is one of the event, even though it's not mandatory. There is PHP framework called Piece Framework that has option regenerate session ID for every request to achieve maximum session ID security, for example. If regeneration of session ID causes misbehavior, then it is a bug including users fault. I think if I disable this feature when TranSID on and/or expire is not 0, then there would not be issues. Unless web programmers use session ID for CSRF protection, etc. Anyway, I'll start from documentation. If there are any comments, I'll appreciate it. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
[PHP-DEV] Regenerating session ID automatically when IP address has changed
Hi all, There isn't any good counter measure session hijack. However, we can regenerate session ID if IP address has changed. Hijacked users might notice that they have been logged out if session ID is regenerated by attackers. Therefore, users have slight chance to notice that they were under attack. It's not greatly effective, but better than nothing. Although this can be implemented in user script, it would be better if session module supports this behavior. Better security by default is good thing. It requires INI, since some apps may assume session ID would not change. (I do not encourage to use session ID for CSRF protection, but there are such implementations, for example.) A concern is that there are growing number of browsers share state. I do not research these browsers behavior yet. I suppose session cookie (expire=0) would not be shared. Anyone has any comments on this? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
Hey: On Tue, Sep 24, 2013 at 10:29 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, There isn't any good counter measure session hijack. However, we can regenerate session ID if IP address has changed. Hijacked users might notice that they have been logged out if session ID is regenerated by attackers. Therefore, users have slight chance to notice that they were under attack. It's not greatly effective, but better than nothing. I don't think this is language concerning issue. it could be done in user script.. thanks Although this can be implemented in user script, it would be better if session module supports this behavior. Better security by default is good thing. It requires INI, since some apps may assume session ID would not change. (I do not encourage to use session ID for CSRF protection, but there are such implementations, for example.) A concern is that there are growing number of browsers share state. I do not research these browsers behavior yet. I suppose session cookie (expire=0) would not be shared. Anyone has any comments on this? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
When you have a group of front-end termination points in a pool, proxying requests off to hundreds of machines for thousands of applications, tying a session to any IP is a headache. IMO, sessions are supposed to be tied to users, not any given inbound IP that can, and may, jump between different routers, proxies, NAT hosts, etc. -Ronabop On Mon, Sep 23, 2013 at 7:29 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, There isn't any good counter measure session hijack. However, we can regenerate session ID if IP address has changed. Hijacked users might notice that they have been logged out if session ID is regenerated by attackers. Therefore, users have slight chance to notice that they were under attack. It's not greatly effective, but better than nothing. Although this can be implemented in user script, it would be better if session module supports this behavior. Better security by default is good thing. It requires INI, since some apps may assume session ID would not change. (I do not encourage to use session ID for CSRF protection, but there are such implementations, for example.) A concern is that there are growing number of browsers share state. I do not research these browsers behavior yet. I suppose session cookie (expire=0) would not be shared. Anyone has any comments on this? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
