Hello,
ext/session lacks the option to check the visitor's IP address and this is
a much needed feature for pretty much everybody writing web applications
today. I'll call it 'session.match_ip' for now.
So much needed in fact, that I'm surprised PHP made it to 2014 without that
option, especially since there already is 'session.referer_check'.
Yes, one can write a custom session handler, but there's a number of
problems with that:
-
Most people don't know enough to do it properly, more specifically - how
to handle concurrency. -
The documentation available is pretty limited.
-
Unless I want another type of storage, why should I bother trying to
replicate ext/session just for this one option?
And of course, there are a few pre-made handlers in PECL, but those are
afaik no longer maintaned and not feasible if you'd be distributing your
end product instead of just running it yourself.
I'd write an RFC about it, but I know it doesn't stand a good chance
without a patch to go with it and I'm not comfortable enough with my C
knowledge to do it myself. It should be simple enough in theory though ...
-
Create an MD5 hash of REMOTE_ADDR and do one of these:
- Prepend it to the session file name
- Create a directory named after it under session.save_path
- Have the option to specify it in session.save_path itself, like it's
done with N and MODE
It shouldn't cause any BC breaks and the only issue I can think of is loss
of existing sessions when the option is being turned On/Off. I wouldn't be
bothered by that really, it should be expected.
So, how do you guys feel about this? Would anybody be willing to write the
patch (I'll do the RFC)?
Cheers,
Andrey Andreev a.k.a. Narf.
Hi!
Yes, one can write a custom session handler, but there's a number of
problems with that:
Wouldn't using SessionHandler and overriding just, say, read() and
adding the IP check there solve this issue? You don't have to bother
with implementing the whole handler, it stays the same but you can check
the IP after the session is loaded (or before if you wish, depending on
what you check does).
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hello,
ext/session lacks the option to check the visitor's IP address and this is
a much needed feature for pretty much everybody writing web applications
today. I'll call it 'session.match_ip' for now.
So much needed in fact, that I'm surprised PHP made it to 2014 without that
option, especially since there already is 'session.referer_check'.Yes, one can write a custom session handler, but there's a number of
problems with that:
Most people don't know enough to do it properly, more specifically - how
to handle concurrency.The documentation available is pretty limited.
Unless I want another type of storage, why should I bother trying to
replicate ext/session just for this one option?And of course, there are a few pre-made handlers in PECL, but those are
afaik no longer maintaned and not feasible if you'd be distributing your
end product instead of just running it yourself.I'd write an RFC about it, but I know it doesn't stand a good chance
without a patch to go with it and I'm not comfortable enough with my C
knowledge to do it myself. It should be simple enough in theory though ...
Create an MD5 hash of REMOTE_ADDR and do one of these:
- Prepend it to the session file name
- Create a directory named after it under session.save_path
- Have the option to specify it in session.save_path itself, like it's
done with N and MODEIt shouldn't cause any BC breaks and the only issue I can think of is loss
of existing sessions when the option is being turned On/Off. I wouldn't be
bothered by that really, it should be expected.So, how do you guys feel about this? Would anybody be willing to write the
patch (I'll do the RFC)?Cheers,
Andrey Andreev a.k.a. Narf.
For the record suhosin supports this(
http://www.hardened-php.net/suhosin/configuration.html#suhosin.session.cryptraddr)
but to quote from the docs:
"Keep in mind that this should not be used on sites that have visitors from
big ISPs, because their IP address often changes during a session. But this
feature might be interesting for admin interfaces or intranets."
I agree with that statement, and this is why this can't be a default
behavior, and given how easy is to extend the default SessionHandler, I'm
not even sure about providing an optional implementation for this.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
On Sat, Jan 25, 2014 at 3:20 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Hi!
Yes, one can write a custom session handler, but there's a number of
problems with that:Wouldn't using SessionHandler and overriding just, say, read() and
adding the IP check there solve this issue? You don't have to bother
with implementing the whole handler, it stays the same but you can check
the IP after the session is loaded (or before if you wish, depending on
what you check does).
I'm not aware of a way to override just read().
But even even if I could, how would I avoid breaking the rest of the
SessionHandler? The manual implies that read() is where (in userland PHP
terms) fopen() + assign file handle + flock() would happen.
Doesn't make much sense for that to be possible.
For the record suhosin supports this(
http://www.hardened-php.net/suhosin/configuration.html#suhosin.session.cryptraddr)
but to quote from the docs:
"Keep in mind that this should not be used on sites that have visitors
from big ISPs, because their IP address often changes during a session. But
this feature might be interesting for admin interfaces or intranets."
I agree with that statement, and this is why this can't be a default
behavior, and given how easy is to extend the default SessionHandler, I'm
not even sure about providing an optional implementation for this.
I'm not suggesting that it should be On by default.
Otherwise, playing with custom session handlers if fun for me, personally.
But trust me when I say this: it is not easy for the majority of people out
there.
Hi!
I'm not aware of a way to override just read().
What would be the problem with it? You can override each method
independently.
But even even if I could, how would I avoid breaking the rest of the
SessionHandler? The manual implies that read() is where (in userland PHP
terms)fopen()+ assign file handle +flock()would happen.
Why would you break it? Just do something like:
class SessionHandlerWithIPChecks extends SessionHandler {
public function SessionHandler::read($session_id)
{
$data = parent::read($session_id);
if(!$this->doChecks($data)) {
return "";
}
return $data;
}
}
Then do:
session_set_save_handler(new SessionHandlerWithIPChecks());
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
Hi!
I'm not aware of a way to override just read().
What would be the problem with it? You can override each method
independently.
You may also consider using open() instead of read(), or both, depending
on what you are actually checking...
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Yes, one can write a custom session handler, but there's a number of
problems with that:
Correct me if I'm wrong, but why would you need to do that? Surely, this
would suffice:
if (!isset($_SESSION['ip'])) {
$_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];
} else if ($_SERVER['REMOTE_ADDR'] !== $_SESSION['ip']) {
`session_destroy()`;
}
--
Andrea Faulds
http://ajf.me/
>
>
>
>>
>> Yes, one can write a custom session handler, but there's a number of
>> problems with that:
>
>
> Correct me if I'm wrong, but why would you need to do that? Surely, this
> would suffice:
>
> if (!isset($_SESSION['ip'])) {
> $_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];
> } else if ($_SERVER['REMOTE_ADDR'] !== $_SESSION['ip']) {
> `session_destroy()`;
> }
>
- I don't want the IP stored in session data, I already know it.
- `filemtime()` result of the potentially targeted session id is
changed, extending its expiry time
- multiple set-cookie headers
Basically, I want it to be perfect. :)
Andrey Andreev wrote:
Yes, one can write a custom session handler, but there's a number of
problems with that:
Correct me if I'm wrong, but why would you need to do that? Surely, this
would suffice:if (!isset($_SESSION['ip'])) { $_SESSION['ip'] = $_SERVER['REMOTE_ADDR']; } else if ($_SERVER['REMOTE_ADDR'] !== $_SESSION['ip']) { `session_destroy()`; }
- I don't want the IP stored in session data, I already know it.
filemtime()result of the potentially targeted session id is
changed, extending its expiry time- multiple set-cookie headers
Basically, I want it to be perfect.:)
Since nowadays the vast majority of 'users' do not have fixed IP addresses, and
the methods used to share IP's on mobile phones is making that even more of a
problem. It has already been pointed out that this can't be a default.
Personally I keep track of the visitor IP's in a database and so have my own
handling and I'm fairly sure most frameworks also do that. So I do not believe
it leaves many options that could be considered safe to use as an alternative?
So to
So much needed in fact, that I'm surprised PHP made it to 2014 without that
option, especially since there already is 'session.referer_check'.
the answer is - because no one can come up with something that is safe to use?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>
>>
>>
>>
>>>
>>> Yes, one can write a custom session handler, but there's a number of
>>> problems with that:
>>
>>
>> Correct me if I'm wrong, but why would you need to do that? Surely, this
>> would suffice:
>>
>> if (!isset($_SESSION['ip'])) {
>> $_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];
>> } else if ($_SERVER['REMOTE_ADDR'] !== $_SESSION['ip']) {
>> `session_destroy()`;
>> }
>>
>
> - I don't want the IP stored in session data, I already know it.
> - `filemtime()` result of the potentially targeted session id is
> changed, extending its expiry time
> - multiple set-cookie headers
>
> Basically, I want it to be perfect. :)
>
Hi all.
Don't bash me when I'm wrong, but why would you want the IP check for
the session in the first place? Don't get me wrong, I'm definitely in
favour of more security, but the issue I see, is the following:
When a user has an ISP that regularrily changes the IP-address assigned
to the user via DHCP the session then is lost, isn't it? So suddenly the
user is logged of without any apparent reason whatsoever.
And if that's not a problem, please take into account the users real
address and not the address of any proxy that is in between (at least
when it's possible to determin it). And that involves a lot of header
checks, whether one or the other is set. And as soon as the appropriate
header is not set (which might be the case due to proxy misbehaviour or
misconfiguration), you will "only" have the IP of the Proxy. So all
users behind such a proxy will share the same IP-address. The same goes
for users behind NAT in a private network.
So there might be so many exceptions that I wouldn't know whether it'a
security benefit or not.
Or am I completely wrong and didn't get the point? Then feel free to
simply ignore this mail.
Andreas
--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org http://hei.gl/wiFKy7 |
+---------------------------------------------------------------------+
| http://hei.gl/root-ca |
+---------------------------------------------------------------------+
> Am 25.01.14 04:15, schrieb Andrey Andreev:
>>
>>>
>>>
>>>
>>>>
>>>> Yes, one can write a custom session handler, but there's a number of
>>>> problems with that:
>>>
>>>
>>> Correct me if I'm wrong, but why would you need to do that? Surely, this
>>> would suffice:
>>>
>>> if (!isset($_SESSION['ip'])) {
>>> $_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];
>>> } else if ($_SERVER['REMOTE_ADDR'] !== $_SESSION['ip']) {
>>> `session_destroy()`;
>>> }
>>>
>>
>> - I don't want the IP stored in session data, I already know it.
>> - `filemtime()` result of the potentially targeted session id is
>> changed, extending its expiry time
>> - multiple set-cookie headers
>>
>> Basically, I want it to be perfect. :)
>>
> Hi all.
>
> Don't bash me when I'm wrong, but why would you want the IP check for
> the session in the first place? Don't get me wrong, I'm definitely in
> favour of more security, but the issue I see, is the following:
> When a user has an ISP that regularrily changes the IP-address assigned
> to the user via DHCP the session then is lost, isn't it? So suddenly the
> user is logged of without any apparent reason whatsoever.
>
> And if that's not a problem, please take into account the users real
> address and not the address of any proxy that is in between (at least
> when it's possible to determin it). And that involves a lot of header
> checks, whether one or the other is set. And as soon as the appropriate
> header is not set (which might be the case due to proxy misbehaviour or
> misconfiguration), you will "only" have the IP of the Proxy. So all
> users behind such a proxy will share the same IP-address. The same goes
> for users behind NAT in a private network.
We have this security feature in userspace code in Horde 3-5, but it's
of limited value because all installations with corporate network users
need to turn it off (because their IPs are constantly changing).
--
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang@b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Ralf Lang wrote:
We have this security feature in userspace code in Horde 3-5, but it's
of limited value because all installations with corporate network users
need to turn it off (because their IPs are constantly changing).
It is probably worth flagging a different problem I've been hitting recently!
Many of the browsers I am serving are at fixed locations, so the machine name/ip
address determines that I'm processing say 'Counter 3' and so I can make
announcements and update displays to call to the correct location. However the
use of 'virtual' devices means that there is no fixed information returned for
the physical device :( The IP address can change between each use of a counter
location as a different 'virtual' device is picked up. Since the ip address is a
critical part of our anti-fraud checks, these sites are now actually failing to
meet critical security requirements, but that is currently being ignored!
Logging the physical location of each session has always worked in the past, but
is now compromised as any device on the network can pretend to be at a secure
location. Cash payment terminals are a good example of a problem area. Properly
implemented the risk can be reduced, but that requires IT departments actually
knowing what they are doing :)
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Hi,
I've just written session_create_id(string $prefix) today.
You can do that easily and securely withsession_create_id().
It would be in 5.6.You may check easily with user script whatever prefix means.
NOTE: No one should not expose sensitive data in prefix!
If anyone would like to prefix by IP address, store it like
session_create_id(sha1($secret.$IP_ADDR).'-');
I want to prefix the session file, because that's just the
easiest/fastest way to do such a check and make it work flawlessly
with 'session.use_strict_mode'. Prefixing the session ID doesn't
prevent hijacking it, because that's client-side input via the cookie.
Since nowadays the vast majority of 'users' do not have fixed IP addresses, and
the methods used to share IP's on mobile phones is making that even more of a
problem. It has already been pointed out that this can't be a default.
Again, I've never said or even thought that it should be a default.
Although, IPv6 is late enough already and the world can't ignore it
forever, so that situation would change at some point in the future.
Also, "not fixed" doesn't necessarily mean changing addresses on every
few minutes and not all web apps have or want to have a "permanent
login" feature. And ultimately - it's the developer's choice.
Personally I keep track of the visitor IP's in a database and so have my own
handling and I'm fairly sure most frameworks also do that. So I do not believe
it leaves many options that could be considered safe to use as an alternative?So to
So much needed in fact, that I'm surprised PHP made it to 2014 without that
option, especially since there already is 'session.referer_check'.
the answer is - because no one can come up with something that is safe to use?
I don't think I undestand what you mean ... is what I'm proposing
somehow unsafe? If so, how?
I'm sure there's a reason why you want that, but I'm not sure I'm seeing
a generic use case for this for core. Why would most of the core users
care how the session files are named and require them named in a
specific way?
I'm saying many, not most.
But while both of these are opinions, I'm quite sure that if we do a
survey, asking the general public - most would say that they want it.
Also, if you hire a security expert to audit your code and
'session.match_ip' is available - put your money on a recommendation
to turn that on.
And true, few people would care about the file name in particular. It
just so happens that performance-wise, that's the best solution.
Don't bash me when I'm wrong, but why would you want the IP check for
the session in the first place? Don't get me wrong, I'm definitely in
favour of more security, but the issue I see, is the following:
When a user has an ISP that regularrily changes the IP-address assigned
to the user via DHCP the session then is lost, isn't it? So suddenly the
user is logged of without any apparent reason whatsoever.
When, but not necessarily.
You could read up a few paragraphs above where I mention IPv6, but you
could also look at some traffic on IRC (just because all addresses are
visible there, unless spoofed) to see that IPs are not in fact that
much regularly changed in general. For an application that doesn't
need a "permanent login" feature, that's not a problem.
And if that's not a problem, please take into account the users real
address and not the address of any proxy that is in between (at least
when it's possible to determin it). And that involves a lot of header
checks, whether one or the other is set. And as soon as the appropriate
header is not set (which might be the case due to proxy misbehaviour or
misconfiguration), you will "only" have the IP of the Proxy. So all
users behind such a proxy will share the same IP-address. The same goes
for users behind NAT in a private network.
These headers can be sent by anybody, effectively spoofing the IP
address and therefore must not be taken into account. I'd say that
this is a rare exception and I can live with people behind a proxy or
NAT sharing the same address - we're kind of forced to. :)
I'm getting the impression that most (if not all) of you are trying
hard to find a reason not to have this feature, with no such reason
existing. It wouldn't be bloat, nor would it break anything.
Ultimately, it's an option, a tool that if you don't need, then you
just don't turn it on. Give us that tool. ;)
Andrey Andreev wrote:
Although, IPv6 is late enough already and the world can't ignore it
forever, so that situation would change at some point in the future.
That everybody has a fixed IP address would be nice but I doubt we will see that
any time soon :(
Also, "not fixed" doesn't necessarily mean changing addresses on every
few minutes and not all web apps have or want to have a "permanent
login" feature. And ultimately - it's the developer's choice.
Actually if you look at the log files on a busy system it's not unusual to have
several ip addresses for an individual user session. Having identified the ISP
one can normally tell when this will happen.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Am 25.01.2014 17:30 schrieb "Andrey Andreev" narf@devilix.net:
Also, "not fixed" doesn't necessarily mean changing addresses on every
few minutes
For some users it means changing addresses at every request. The
traditional thing was the AOL Proxy. I regularly see the same for mobile
provider users from places like Singapore, and for mobile Opera browser
users that run through "optimizing" proxies run by Opera. With the current
Google Chrome update such a "feature" arrives in google world, so over the
next year it will become even more common place - probably making geoIP
also a thing of the glorious past...
So, unless you know your userbase exactly and know exactly that they will
not be affected by such issues, fixing the session to the client IP just
doesn't fly.
best regards
Patrick
Am 25.01.2014 17:30 schrieb "Andrey Andreev" narf@devilix.net:
Also, "not fixed" doesn't necessarily mean changing addresses on every
few minutesFor some users it means changing addresses at every request.
I've seen the initial page and subsequent image requests for a single
page load come from different IP addresses.
I've seen the initial page and subsequent image requests for a single
page load come from different IP addresses.
It certainly happens.
Ultimately, though, the question isn't just about ultradynamic IPs.
It's simply about the acceptable percentage of humans whose session
expiry will be 1 or 2 minutes when everybody else's is 10m or more.
These people will be unwilling to use your site if you implement this
feature and do not allow the user to turn it off him/herself if
necessary.
For our site, a team-based web app, that percentage is zero. We
cannot under any circumstances prohibit somebody from inviting another
user who happens to roam on cellular or heavily proxied networks. I
must also allow the team manager to easily manage such a setting on
behalf of their reports, who are frequently not as technically savvy
and certainly don't want to race to get to their User Profile area in
time.
We're also addressing attackers who have sniffed your encrypted
traffic and can wedge in-between your constantly-changing session IDs
-- significant security measures that have no such collateral damage.
I guess the attackers have client certs covered as well. (Of course,
if they have this level of ownership, there's a good chance they're
being NATted through your same source IP anyway!) Is it worth shedding
potential users, potentially killing your entire business if it is
collaborative in nature, in order to thwart this probably-null set of
potential attackers? I say no, and any security auditor who
automatically penalizes you if you don't say "yes" isn't doing his/her
job.
-- Sandy