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
yohgaki@ohgaki.net
Hey:
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
yohgaki@ohgaki.net
--
Laruence Xinchen Hui
http://www.laruence.com/
Hi Laruence,
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
yohgaki@ohgaki.net
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.
Hi,
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
Hi Tjerk,
On Thu, Sep 26, 2013 at 7:32 PM, Tjerk Meesters tjerk.meesters@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
yohgaki@ohgaki.net
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.
Hi Sanford,
On Fri, Sep 27, 2013 at 7:57 AM, Sanford Whiteman <
swhitemanlistens-software@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
yohgaki@ohgaki.net
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.
Hi Standord,
On Fri, Sep 27, 2013 at 9:45 AM, Sanford Whiteman <
swhitemanlistens-software@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
yohgaki@ohgaki.net
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...
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.
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.
Am 27.09.13 12:12, schrieb Leigh:
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: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 |
+---------------------------------------------------------------------+
On 26 September 2013 11:32, Tjerk Meesters tjerk.meesters@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.
--
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
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.
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
PeterAnd 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
Hi,
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
PeterAnd 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
Hi Leigh,
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
- Generally speaking, more frequent session ID regeneration is more
security. - 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
yohgaki@ohgaki.net
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.
Hi Leigh,
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
- Generally speaking, more frequent session ID regeneration is more
security.- 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
yohgaki@ohgaki.net
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
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.
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
... 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.
On Sat, Sep 28, 2013 at 2:07 PM, Sanford Whiteman
swhitemanlistens-software@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
Hi Leigh,
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
- 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.
- 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
yohgaki@ohgaki.net
--
Tjerk
On Mon, Sep 30, 2013 at 4:51 PM, Tjerk Meesters tjerk.meesters@gmail.comwrote:
Hi Leigh,
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
- 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.
- 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), orb) 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
yohgaki@ohgaki.net
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
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
yohgaki@ohgaki.net
Hi,
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
yohgaki@ohgaki.net
Hi,
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:
- Binding session to IP doesn't work at scale.
- Seeing that the IP has "changed" is totally useless to detect hijacking.
- Session libraries that are expecting state, on the internet, are
fundamentally broken by design.
-Ronabop
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.
Hi Mike,
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
yohgaki@ohgaki.net
Why couldn't this be implemented on userland again? I don't feel this
is a language level issue.
Hi Mike,
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
yohgaki@ohgaki.net
Hi Madara,
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
yohgaki@ohgaki.net
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
yohgaki@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