Binding ip address with session

[mebjas]

Owasp cheat sheet for session management says we should bind session to ip address to make it more secure. Why didnt we go for this in PHPSEC.?

[SvenRtbg]

You are not completely correct.

https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Binding_the_Session_ID_to_Other_User_Properties

With the goal of detecting user misbehaviors and session hijacking, it is highly recommended to bind the session ID to other user or client properties, such as the client IP address, User-Agent, or client-based digital certificate.

Using the IP is mentioned as one example, but is not recommended as the ONLY method. In fact using the IP can have it's consequences for the application and should be considered by the developer only, not be the default. The user agent string on the other hand seems like a sufficient source of uniqueness, because in the scenario of a valid session it will never change (the user will not switch the browser and manually transfer the cookie to continue his session - not allowing such a use case is ok). An attacker would still be able to abuse this, but would have to know the user agent string as well (which might be completely easy if he is able to eavesdrop the connection, but I consider this rarely to be the case).

[mebjas]

As it is mentioned binding IP is one possible option. Would a normal user suffer a change in IP during the session? also for an attacker who can forge IP value, it wont be difficult to forge user-agent as well, then whats the difference?

[SvenRtbg]

Would a normal user suffer a change in IP during the session?

Yes. People disconnect and reconnect all the time, just think of mobile phones. Their provider probably would be able to route the user through the same proxy and external IP, but there is no guarantee.

Also there is the saying that in the old days, users of AOL were behind a proxy farm with plenty of external IP's, and they would randomly appear on more than one. Having a session rely on the user keeping his IP address is asking for trouble.

And no, IP addresses cannot be easily faked. An attacker will be able to send UDP or TCP packets with a forged address, but he is very unlikely to get an answer back. So there really is more security involved with IP pinning the session, but this cannot be a solution that fits everyone.

If you want to make a business and depend on everyone to reach your site, loosing any percentage of users because they cannot log in will likely result in our library to not be used. In a special use case with very high security demand however, it should be done.

[abiusx]

It is a good idea to pin the IP, and not a good idea to pin the other user behaviors (that requires a lot of logic and an IDS), but the exact IP is not the thing that is checked, the IP geolocation is checked, and if it changes, the new geolocation difference is computed. It is not possible for someone to move 1000 miles in 2 minutes.

Of course attackers bypass this by obtaining an IP in the range, and most applications just ignore this check when a user is randomly appearing from different places (facebook, gmail), but its a good feature to have in (and toggle with a boolean). -A

---

Notice: This message is digitally signed, its source and integrity are verifiable. If you mail client does not support S/MIME verification, it will display a file (smime.p7s), which includes the X.509 certificate and the signature body. Read more at Certified E-Mail with Comodo and Thunderbird in AbiusX.com

On Feb 19, 2014, at 4:58 PM, SvenRtbg notifications@github.com wrote:

Would a normal user suffer a change in IP during the session?

Yes. People disconnect and reconnect all the time, just think of mobile phones. Their provider probably would be able to route the user through the same proxy and external IP, but there is no guarantee.

Also there is the saying that in the old days, users of AOL were behind a proxy farm with plenty of external IP's, and they would randomly appear on more than one. Having a session rely on the user keeping his IP address is asking for trouble.

And no, IP addresses cannot be easily faked. An attacker will be able to send UDP or TCP packets with a forged address, but he is very unlikely to get an answer back. So there really is more security involved with IP pinning the session, but this cannot be a solution that fits everyone.

If you want to make a business and depend on everyone to reach your site, loosing any percentage of users because they cannot log in will likely result in our library to not be used. In a special use case with very high security demand however, it should be done.

— Reply to this email directly or view it on GitHub.

[shivamdixit]

If we have to check geolocation of an IP then are we going to use some API like google Geolocation API ? If yes then an overhead of making an API call and waiting for its response will slow down the whole process.

Can we make this API call asynchronous ?

[abiusx]

It almost can’t be async, but PHP and GeoIP work together pretty well. Duller algorithms just check IP ranges, but that results in a lot of false positives. There is a DAT file database for local GeoIP in PHP. City-wide locality is probably good enough. -A

---

Notice: This message is digitally signed, its source and integrity are verifiable. If you mail client does not support S/MIME verification, it will display a file (smime.p7s), which includes the X.509 certificate and the signature body. Read more at Certified E-Mail with Comodo and Thunderbird in AbiusX.com

On Feb 19, 2014, at 9:30 PM, Shivam Dixit notifications@github.com wrote:

If we have to check geolocation of an IP then are we going to use some API like google Geolocation API ? If yes then an overhead of making an API call and waiting for its response will slow down the whole process.

Can we make this API call asynchronous ?

— Reply to this email directly or view it on GitHub.

[SvenRtbg]

Note that "IP" does not inherently mean a thing like "127.0.0.1" which is unlikely to change, but also "::1" or "2001:DB8:FF01:AAAA:FFFF:FFFF:FFFF:FFFF", with the last 64 bits changing randomly during usage, and probably the middle 56th to 64th bit (AAAA) also being likely to change. Yes, I am talking IPv6 here.

[abiusx]

Yes IPV6 is tricky guys, you definitely wanna test it somehow, or disable this feature if an IP not of Ipv4 format is observed. -A

---

Notice: This message is digitally signed, its source and integrity are verifiable. If you mail client does not support S/MIME verification, it will display a file (smime.p7s), which includes the X.509 certificate and the signature body. Read more at Certified E-Mail with Comodo and Thunderbird in AbiusX.com

On Feb 20, 2014, at 7:25 PM, SvenRtbg notifications@github.com wrote:

Note that "IP" does not inherently mean a thing like "127.0.0.1" which is unlikely to change, but also "::1" or "2001:DB8:FF01:AAAA:FFFF:FFFF:FFFF:FFFF", with the last 64 bits changing randomly during usage, and probably the middle 56th to 64th bit (AAAA) also being likely to change. Yes, I am talking IPv6 here.

— Reply to this email directly or view it on GitHub.

[SvenRtbg]

Why is this closed with no explanation (like a statement "won't implement") or commit/pull request?

[mebjas]

I closed it, because there was no conclusion to the discussion, and it is dated back to december 2013. Do we need this one open?

[SvenRtbg]

If it is an issue that should some day be worked on, it should be open. If you decide that we do not want to work on it, close it with a comment stating this decision. Others will probably read this and know why it was closed and whom to ask why if they disagree.

[MysterAitch]

I believe this can be addressed by the feature suggestion posted in #103, if implemented.

My 2c: +1 for leaving unresolved issues open. After all, they are unresolved (open). Closing them is like sweeping it under the carpet (IMO a bad thing).