Sessions and Security Concerns

--00163641780b4d557f0482eec1d9
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I'm just wondering whether there are any apparent security concerns I should
be aware of when using sessions in my PHP scripts. I understand that
sessions are tracked with an individual user via a session ID which is
stored in a temporary location on the server, as well as a PHPSESSID cookie
assigned to the end user's client, but the server my website is hosted on
(and which I'll be developing my PHP script on) doesn't allow you to create
a session ID via the URL (i.e. index.php?PHPSESSID=1234) so I *presume* only
the server can generate a session ID for the end user when I call the
session_start function? So do I still need to call session_regenerate_id for
security purposes when an end user has entered the correct login credentials
- would this be necessary since you cant set a session ID via the URL?

Thanks,
Ben.

--00163641780b4d557f0482eec1d9--

Re: Sessions and Security Concerns

--=-z0lA1rgA7WM2VBgR/lMe
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Mon, 2010-03-29 at 12:24 +0100, Ben Stones wrote:

> Hi,
>
> I'm just wondering whether there are any apparent security concerns I should
> be aware of when using sessions in my PHP scripts. I understand that
> sessions are tracked with an individual user via a session ID which is
> stored in a temporary location on the server, as well as a PHPSESSID cookie
> assigned to the end user's client, but the server my website is hosted on
> (and which I'll be developing my PHP script on) doesn't allow you to create
> a session ID via the URL (i.e. index.php?PHPSESSID=1234) so I *presume* only
> the server can generate a session ID for the end user when I call the
> session_start function? So do I still need to call session_regenerate_id for
> security purposes when an end user has entered the correct login credentials
> - would this be necessary since you cant set a session ID via the URL?
>
> Thanks,
> Ben.


Just setting a URL variable won't actually create a session, you have to
use the PHP session functions to create one.

Using session_regenerate_id() won't do that much for security. If you
are really worried, then consider a security certificate. Even a
self-issued one is better than nothing, and you can generate these for
free.

Thanks,
Ash
http://www.ashleysheridan.co.uk



--=-z0lA1rgA7WM2VBgR/lMe--

Re: Sessions and Security Concerns

Ashley Sheridan wrote:
> On Mon, 2010-03-29 at 12:24 +0100, Ben Stones wrote:
>
>> Hi,
>>
>> I'm just wondering whether there are any apparent security concerns I should
>> be aware of when using sessions in my PHP scripts. I understand that
>> sessions are tracked with an individual user via a session ID which is
>> stored in a temporary location on the server, as well as a PHPSESSID cookie
>> assigned to the end user's client, but the server my website is hosted on
>> (and which I'll be developing my PHP script on) doesn't allow you to create
>> a session ID via the URL (i.e. index.php?PHPSESSID=1234) so I *presume* only
>> the server can generate a session ID for the end user when I call the
>> session_start function? So do I still need to call session_regenerate_id for
>> security purposes when an end user has entered the correct login credentials
>> - would this be necessary since you cant set a session ID via the URL?
>>
>> Thanks,
>> Ben.
>
>
> Just setting a URL variable won't actually create a session, you have to
> use the PHP session functions to create one.
>
> Using session_regenerate_id() won't do that much for security. If you
> are really worried, then consider a security certificate. Even a
> self-issued one is better than nothing, and you can generate these for
> free.

worth noting that you can also issue client side ssl certificates to
your users; 100% secure, self-signed thus free, either by creating a
pki12 w/ php or by using the html KEYGEN element - the ssl cert installs
directly in the users browser. You can use the subjectAltName attribute
of the certificate to save a users unique id.

And thus, 0 click login, perfectly secure auth all done through https -
further meaning you can completely negate sessions/cookies and all the
related insecurities.

further still, you can boot this up to foaf+ssl giving users one unique
web id for themselves, and in full control of there own profile / login
etc; (like openid done right and one steriods)

Will be the defacto industry standard in a couple of years, so may as
well adopt early.

Regards!

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php