[PHP-DEV] Session security

php-dev, [PHP-DEV] Session security Hi all,

Just wanted to get your opinion on a discussion currently going on on
the general list.

Why does the PHP session extension not use something like the user agent
to validate that a session ID has not been hijacked? Or is this
something that just hasn't been implemented yet?

-Stut

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

php-dev >> [PHP-DEV] Session security On 29.05.2007 21:04, Stut wrote:
> Hi all,
>
> Just wanted to get your opinion on a discussion currently going on on
> the general list.
>
> Why does the PHP session extension not use something like the user agent
> to validate that a session ID has not been hijacked? Or is this
> something that just hasn't been implemented yet?

Please elaborate.

--
Wbr,
Antony Dovgal

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

php-dev >> [PHP-DEV] Session security Stut wrote:
> Hi all,
>
> Just wanted to get your opinion on a discussion currently going on on
> the general list.
>
> Why does the PHP session extension not use something like the user agent
> to validate that a session ID has not been hijacked? Or is this
> something that just hasn't been implemented yet?

The user agent is trivial to spoof. If you are going to hijack
someone's session, it is very easy to also hijack their user agent
string, so I don't see how that solves anything.

-Rasmus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

php-dev >> [PHP-DEV] Session security Stut 鍐欓亾:
> Hi all,
>
> Just wanted to get your opinion on a discussion currently going on on
> the general list.
>
> Why does the PHP session extension not use something like the user
> agent to validate that a session ID has not been hijacked? Or is this
> something that just hasn't been implemented yet?
>
> -Stut
>
Some http proxy may modify the user agent~
If there are some http proxy in a cluster, and one of them do some
different on user agent, there must be a trouble.

And, the other way, to aganst the attacker getting the real user agent,
we could do something like: md5(user agent + secrete key) . then if the
attacker get the string of md5, it is no use to forge the real user agent.
Any way, this should be done in the script layer, not in the session
mechanism. you need more security, do it in script, needn't, do nothing~~

Xing

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

php-dev >> [PHP-DEV] Session security On Tue, 2007-05-29 at 10:16 -0700, Rasmus Lerdorf wrote:
> Stut wrote:
> > Hi all,
> >
> > Just wanted to get your opinion on a discussion currently going on on
> > the general list.
> >
> > Why does the PHP session extension not use something like the user agent
> > to validate that a session ID has not been hijacked? Or is this
> > something that just hasn't been implemented yet?
>
> The user agent is trivial to spoof. If you are going to hijack
> someone's session, it is very easy to also hijack their user agent
> string, so I don't see how that solves anything.

I agree mostly, but in the case of idiots that post a URL to a site that
includes a PHPSESSID in the URL it would provide a teency bit more
protection from casual hijacking :)

I agree more with Xing Xing's responde though, in that it belongs in the
script layer.

Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

php-dev >> [PHP-DEV] Session security Robert Cummings wrote:
> On Tue, 2007-05-29 at 10:16 -0700, Rasmus Lerdorf wrote:
>> Stut wrote:
>>> Hi all,
>>>
>>> Just wanted to get your opinion on a discussion currently going on on
>>> the general list.
>>>
>>> Why does the PHP session extension not use something like the user agent
>>> to validate that a session ID has not been hijacked? Or is this
>>> something that just hasn't been implemented yet?
>> The user agent is trivial to spoof. If you are going to hijack
>> someone's session, it is very easy to also hijack their user agent
>> string, so I don't see how that solves anything.
>
> I agree mostly, but in the case of idiots that post a URL to a site that
> includes a PHPSESSID in the URL it would provide a teency bit more
> protection from casual hijacking :)
>
> I agree more with Xing Xing's responde though, in that it belongs in the
> script layer.

Well, obviously you need an authentication layer separate from the
session layer. If people are using the session extension as if it was
an authentication layer, then they are amazingly misguided. The
solution to that is not the session code, but better documentation.

-Rasmus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

php-dev >> [PHP-DEV] Session security On Tue, 2007-05-29 at 11:14 -0700, Rasmus Lerdorf wrote:
> Robert Cummings wrote:
> > On Tue, 2007-05-29 at 10:16 -0700, Rasmus Lerdorf wrote:
> >> Stut wrote:
> >>> Hi all,
> >>>
> >>> Just wanted to get your opinion on a discussion currently going on on
> >>> the general list.
> >>>
> >>> Why does the PHP session extension not use something like the user agent
> >>> to validate that a session ID has not been hijacked? Or is this
> >>> something that just hasn't been implemented yet?
> >> The user agent is trivial to spoof. If you are going to hijack
> >> someone's session, it is very easy to also hijack their user agent
> >> string, so I don't see how that solves anything.
> >
> > I agree mostly, but in the case of idiots that post a URL to a site that
> > includes a PHPSESSID in the URL it would provide a teency bit more
> > protection from casual hijacking :)
> >
> > I agree more with Xing Xing's responde though, in that it belongs in the
> > script layer.
>
> Well, obviously you need an authentication layer separate from the
> session layer. If people are using the session extension as if it was
> an authentication layer, then they are amazingly misguided. The
> solution to that is not the session code, but better documentation.

Well the two are quite related. Not that the session is responsible for
authentication, but once authenticated the session data (stored server
side I hope) usually indicates whether a user has already performed
authentication for the current temporary session -- otherwise you'd need
to log back in on every request. As such, a URL posted in the wild
containing a PHPSESSID is vulnerable to hijacking for the lifespan of
the temporary session. Better documentation won't help the completely
ignorant masses of end users :)

Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

php-dev >> [PHP-DEV] Session security Robert Cummings wrote:
> On Tue, 2007-05-29 at 11:14 -0700, Rasmus Lerdorf wrote:
>> Robert Cummings wrote:
>>> On Tue, 2007-05-29 at 10:16 -0700, Rasmus Lerdorf wrote:
>>>> Stut wrote:
>>>>> Hi all,
>>>>>
>>>>> Just wanted to get your opinion on a discussion currently going on on
>>>>> the general list.
>>>>>
>>>>> Why does the PHP session extension not use something like the user agent
>>>>> to validate that a session ID has not been hijacked? Or is this
>>>>> something that just hasn't been implemented yet?
>>>> The user agent is trivial to spoof. If you are going to hijack
>>>> someone's session, it is very easy to also hijack their user agent
>>>> string, so I don't see how that solves anything.
>>> I agree mostly, but in the case of idiots that post a URL to a site that
>>> includes a PHPSESSID in the URL it would provide a teency bit more
>>> protection from casual hijacking :)
>>>
>>> I agree more with Xing Xing's responde though, in that it belongs in the
>>> script layer.
>> Well, obviously you need an authentication layer separate from the
>> session layer. If people are using the session extension as if it was
>> an authentication layer, then they are amazingly misguided. The
>> solution to that is not the session code, but better documentation.
>
> Well the two are quite related. Not that the session is responsible for
> authentication, but once authenticated the session data (stored server
> side I hope) usually indicates whether a user has already performed
> authentication for the current temporary session -- otherwise you'd need
> to log back in on every request. As such, a URL posted in the wild
> containing a PHPSESSID is vulnerable to hijacking for the lifespan of
> the temporary session. Better documentation won't help the completely
> ignorant masses of end users :)

You really want a separate and distinct signed authentication cookie
that has nothing to do with the session. The stored session should
indicate which logged in user the session belongs to, but it should
never ever be used as the sole authentication cookie. That's what I
meant by a separate authentication layer.

-Rasmus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

php-dev >> [PHP-DEV] Session security Rasmus Lerdorf wrote:
> You really want a separate and distinct signed authentication cookie
> that has nothing to do with the session. The stored session should
> indicate which logged in user the session belongs to, but it should
> never ever be used as the sole authentication cookie. That's what I
> meant by a separate authentication layer.

Thanks to everyone for their responses.

The issue is not about how a user is initially validated, it's about how
you prevent the session ID from being used on a different machine while
it's still active on the server. AFAICT using a signed authentication
cookie will not do this since it's still coming from the client and can
therefore be copied.

The basic question is... is there any way to validate that a session ID
coming from the client is coming from the same client?

I don't believe there is since, as Xing pointed out, anything that comes
from the client can a) be faked, and b) may change from request to
request. This includes the user agent and IP address.

However, I'd like clarification on that just in case there's a reliable
way to make sessions more secure. Oh, and also to validate the argument
I'm making on PHP-General, but that's really a secondary goal ;)

Cheers.

-Stut

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

php-dev >> [PHP-DEV] Session security >> You really want a separate and distinct signed authentication cookie
>> that has nothing to do with the session. The stored session should
>> indicate which logged in user the session belongs to, but it should
>> never ever be used as the sole authentication cookie. That's what I
>> meant by a separate authentication layer.

Could you explain why? If you can steal session cookie, you definitely
could steal any other cookie too. So stealing-wise, nothing is gained by
using separate cookie. Signing would help you to know the cookie is from
you, but I don't see how it's going to help you to know the cookie
belongs to whoever is attempting to use it. Could you elaborate?
--
Stanislav Malyshev, Zend Products Engineer
email***@***.com http://www.zend.com/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

php-dev >> [PHP-DEV] Session security > The basic question is... is there any way to validate that a session ID
> coming from the client is coming from the same client?

I'm afraid since there's no way (well, except for described below :) to
uniquely and securely identify the clients I don't see how you could do
that. You could use client certificates as a secure client
identification, and then probably you could verify that current client
presented the same valid certificate as before, but that doesn't really
belong to sessions - it's external to sessions. Not sure how well PHP
support for client certificates is, in any case unless you have a lot of
control over your users they probably won't like to install any
certificates.

Also, if you use SSL (which you probably do if you care about security),
as I see it most frequent way to steal the cookie is to control user's
browser. If the hostile code gained control over the user's browser,
it's essentially the same client, so you couldn't distinguish it from
the legitimate code. You could of course tryng to counter replay attacks
(which are only part of the possible attacks) by matching IPs and other
auxiliary data but if you don't have secure ID for the client there
would be cases when it could be still not enough.

--
Stanislav Malyshev, Zend Products Engineer
email***@***.com http://www.zend.com/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

php-dev >> [PHP-DEV] Session security --Apple-Mail-3-297288992
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed

On 29 May 2007, at 7:16 PM, Rasmus Lerdorf wrote:

> Stut wrote:
>> Hi all,
>>
>> Just wanted to get your opinion on a discussion currently going on on
>> the general list.
>>
>> Why does the PHP session extension not use something like the user
>> agent
>> to validate that a session ID has not been hijacked? Or is this
>> something that just hasn't been implemented yet?
>
> The user agent is trivial to spoof. If you are going to hijack
> someone's session, it is very easy to also hijack their user agent
> string, so I don't see how that solves anything.
>
I think he's trying to figure out how to do something similar to using a
'browser fingerprint' as part of his session. One thing I noticed with
doing creating and checking a 'browser fingerprint' a few years back
was depending on what you were doing / using it would change things
between requests.

With web requests, a lot of things are easy to spoof from the client
side.
Locking a session to an IP address has it uses provided the user does
not make their requests from various IP addresses like the AOL proxy
farms used to do afaik.

If you are really paranoid, use SSL and regenerate the session
identifier
on the first request from the user. That way it's not known. It's
generally
advised to regenerate the session identifier on privilege change.

There is no real way of detecting if a session has been hijacked
given for
example for .za users we tend to be transparently proxied for
requests to
international sites, so forcing locking a session to a IP will lock
that session
to an ISP's netcache.

Something along the lines of:

if (!isset($_SESSION['initiated'])) {
session_regenerate_id();
$_SESSION['initiated'] = true;
}

When you change privilege do something along the lines of

session_regenerate_id(true);

Which will delete the previous session and keep the current session
information.

YMMV.

Regards
--jm

> -Rasmus

#include <std/disclaimer.h>

--Apple-Mail-3-297288992--

php-dev >> [PHP-DEV] Session security Stanislav Malyshev wrote:
>>> You really want a separate and distinct signed authentication cookie
>>> that has nothing to do with the session. The stored session should
>>> indicate which logged in user the session belongs to, but it should
>>> never ever be used as the sole authentication cookie. That's what I
>>> meant by a separate authentication layer.
>
> Could you explain why? If you can steal session cookie, you definitely
> could steal any other cookie too. So stealing-wise, nothing is gained by
> using separate cookie. Signing would help you to know the cookie is from
> you, but I don't see how it's going to help you to know the cookie
> belongs to whoever is attempting to use it. Could you elaborate?

The session store is just a session store. It is not a
login/authentication mechanism and thus doesn't have any of the
protections you might want to add to that. Therefore a separate
authentication cookie is needed that can separate the two concepts
completely. This also allows you to have different timeouts on the two.
For example, many sites let you stay logged in for weeks, but for any
critical operation they have a much shorter timeout so they ask you to
re-enter your credentials in order to perform that critical action.

Also, any pages that have some sort of user action, typically a form,
will have a crumb in it which is a small signed bit of data which is
usually in a hidden field. This helps prevent cross site request
forgeries by making each form specific to the logged in user.

But yes, there isn't any standard approach to prevent cookie theft. It
is up to the application to come up with a set of checks and
restrictions that best meet the specific needs of that app.

-Rasmus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

php-dev >> [PHP-DEV] Session security > The session store is just a session store. It is not a
> login/authentication mechanism and thus doesn't have any of the
> protections you might want to add to that. Therefore a separate
> authentication cookie is needed that can separate the two concepts

I don't see how it's "therefore". Yes, session is just a storage. But
how you derive from it that authentication information can not be stored
in this storage and how the separate cookie is helping you in any way
make it more secure?

> completely. This also allows you to have different timeouts on the two.

That's a very specific case which doesn't really concern security but
site policies. You could also expire values inside session, there are
numerous wrappers doing it AFAIK, and even if you don't use such wrapper
there's nothing hard in storing timestamp inside the session and
expiring auth once the timestamp goes old.

> For example, many sites let you stay logged in for weeks, but for any
> critical operation they have a much shorter timeout so they ask you to
> re-enter your credentials in order to perform that critical action.

That doesn't mean it should be implemented using separate cookie.

> Also, any pages that have some sort of user action, typically a form,
> will have a crumb in it which is a small signed bit of data which is
> usually in a hidden field. This helps prevent cross site request
> forgeries by making each form specific to the logged in user.

That's nice but again is not related to cookies or sessions. This can be
done without having separate auth cookie.
--
Stanislav Malyshev, Zend Products Engineer
email***@***.com http://www.zend.com/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

php-dev >> [PHP-DEV] Session security Stanislav Malyshev wrote:
>> The session store is just a session store. It is not a
>> login/authentication mechanism and thus doesn't have any of the
>> protections you might want to add to that. Therefore a separate
>> authentication cookie is needed that can separate the two concepts
>
> I don't see how it's "therefore". Yes, session is just a storage. But
> how you derive from it that authentication information can not be stored
> in this storage and how the separate cookie is helping you in any way
> make it more secure?

Because you don't have full control over the session cookie since it is
generated by PHP. For an authentication cookie you want to layer other
application-specific checks on top of it.

-Rasmus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

php-dev >> [PHP-DEV] Session security Rasmus Lerdorf wrote:
> Stanislav Malyshev wrote:
>>> The session store is just a session store. It is not a
>>> login/authentication mechanism and thus doesn't have any of the
>>> protections you might want to add to that. Therefore a separate
>>> authentication cookie is needed that can separate the two concepts
>> I don't see how it's "therefore". Yes, session is just a storage. But
>> how you derive from it that authentication information can not be stored
>> in this storage and how the separate cookie is helping you in any way
>> make it more secure?
>
> Because you don't have full control over the session cookie since it is
> generated by PHP. For an authentication cookie you want to layer other
> application-specific checks on top of it.

I'm still unclear on how you validate that the authentication cookie
came from the same client machine as the one the application first sent
it to, which was the core of my question.

The answer seems to be that you can't do it reliably.

-Stut

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

php-dev >> [PHP-DEV] Session security > Because you don't have full control over the session cookie since it is
> generated by PHP. For an authentication cookie you want to layer other
> application-specific checks on top of it.

Could you give an example of such checks?
--
Stanislav Malyshev, Zend Products Engineer
email***@***.com http://www.zend.com/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

php-dev >> [PHP-DEV] Session security On Tue, 2007-05-29 at 21:11 +0100, Stut wrote:
> Rasmus Lerdorf wrote:
> > Stanislav Malyshev wrote:
> >>> The session store is just a session store. It is not a
> >>> login/authentication mechanism and thus doesn't have any of the
> >>> protections you might want to add to that. Therefore a separate
> >>> authentication cookie is needed that can separate the two concepts
> >> I don't see how it's "therefore". Yes, session is just a storage. But
> >> how you derive from it that authentication information can not be stored
> >> in this storage and how the separate cookie is helping you in any way
> >> make it more secure?
> >
> > Because you don't have full control over the session cookie since it is
> > generated by PHP. For an authentication cookie you want to layer other
> > application-specific checks on top of it.
>
> I'm still unclear on how you validate that the authentication cookie
> came from the same client machine as the one the application first sent
> it to, which was the core of my question.
>
> The answer seems to be that you can't do it reliably.

You don't have any cookie if the user has cookies disabled. So either
you use a policy that enforces the user to enable cookies or you fall
back on trans sid in which case, all bets are off since all you have is
the PHPSESSID stuck in the URL or form POST.

Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

php-dev >> [PHP-DEV] Session security > I'm still unclear on how you validate that the authentication cookie
> came from the same client machine as the one the application first sent
> it to, which was the core of my question.
>
> The answer seems to be that you can't do it reliably.

As far as I understand, no, you can't, unless you have secure external
means to establish client identity (like client certificate).
--
Stanislav Malyshev, Zend Products Engineer
email***@***.com http://www.zend.com/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

php-dev >> [PHP-DEV] Session security Stut wrote:
> Rasmus Lerdorf wrote:
>> Stanislav Malyshev wrote:
>>>> The session store is just a session store. It is not a
>>>> login/authentication mechanism and thus doesn't have any of the
>>>> protections you might want to add to that. Therefore a separate
>>>> authentication cookie is needed that can separate the two concepts
>>> I don't see how it's "therefore". Yes, session is just a storage. But
>>> how you derive from it that authentication information can not be stored
>>> in this storage and how the separate cookie is helping you in any way
>>> make it more secure?
>>
>> Because you don't have full control over the session cookie since it is
>> generated by PHP. For an authentication cookie you want to layer other
>> application-specific checks on top of it.
>
> I'm still unclear on how you validate that the authentication cookie
> came from the same client machine as the one the application first sent
> it to, which was the core of my question.
>
> The answer seems to be that you can't do it reliably.

Correct, which is why it needs to be up to the application. You may
deem it appropriate to do it based on ip because your user base aren't
likely to be coming from AOL or other dynamic connections, or you may
find it useful to tie it to the user agent, or some other mechanism
entirely. Like an RSA token plugin thing, for example. But at the
general level that can't really be hardcoded into PHP since the right
answer will be different for everyone.

-Rasmus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php