Re: Sessions and Security Concerns
| From: | Nathan Rixham | Date: | Mon, 29 Mar 2010 11:59:42 +0000 |
| Subject: | Re: Sessions and Security Concerns | ||
| References: | 1 2 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-303593@lists.php.net to get a copy of this message | ||
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!