-> PHP4 Singleton implementation question <-

Message-ID: <lb2dnbcO6NE30OvYnZ2dnUVZ_qOdnZ2d@comcast.com> from Jerry
Stuckle contained the following:

>> So - as long as I explicitly reference $_SESSION[] when continuing a
>> session, I'm not subject to the security vulnerabilities of
>> register_globals, right?
>>
>
>True - but ANY misstep can be disastrous. The problem is,
>
>$i = $MyVar;
>
>doesn't cause an error of $MyVar hasn't been explicitly assigned a value
>in your code, but it is in the $_SESSION, $_POST, $_GET or $_COOKIES
>(forgot the last one)

$_REQUEST ?

--
Geoff Berrow (put thecat out to email)
It's only Usenet, no one dies.
My opinions, not the committee's, mine.
Simple RFDs http://www.ckdog.co.uk/rfdmaker/

On Wed, 06 Dec 2006 04:04:21 GMT, Sanders Kaufman <bucky@kaufman.net>
wrote:

>Jerry Stuckle wrote:
>> Sanders Kaufman wrote:
>
>>> If not - then the whole security issue is resolved by using $_GET and
>>> $_POST correctly, right?
>>
>> Yes, you can use $_GET and $_POST (and $_SESSION). And if you leave
>> register_globals off, then you *must* use them. Less chance for error.
>
>So - as long as I explicitly reference $_SESSION[] when continuing a
>session, I'm not subject to the security vulnerabilities of
>register_globals, right?

If it is possible to switch register_globals OFF I would very strongly
recommend it. Most hosting companies will have the ability to switch
it on/off per domain or server and it will be much better for
peace-of-mind of you get it switched off.

I recently had a problem when the site that I had been working on
in-house started coming up with all kinds of problems when it was run
on the 'proper', commercial host. Turned out that register_globals was
on, even though they were running PHP4.3 (nice eh?!) and I had session
variables like $_SESSION['userid'] and later in my code I had used
what I assumed would be local variables like $userid ... and of course
they were the same thing and were corrupting each other! Grrr Turning
register_globals off for that domain fixed the problem immediately.

>One more thing - on the session token.
>I notice that PHP puts it in the query string.
>Is it possible to force that into a cookie?

This is another configuration issue that you should be able to discuss
with your host.

Chris R.

Geoff Berrow wrote:
> Message-ID: <lb2dnbcO6NE30OvYnZ2dnUVZ_qOdnZ2d@comcast.com> from Jerry
> Stuckle contained the following:
>
>
>>>So - as long as I explicitly reference $_SESSION[] when continuing a
>>>session, I'm not subject to the security vulnerabilities of
>>>register_globals, right?
>>>
>>
>>True - but ANY misstep can be disastrous. The problem is,
>>
>>$i = $MyVar;
>>
>>doesn't cause an error of $MyVar hasn't been explicitly assigned a value
>>in your code, but it is in the $_SESSION, $_POST, $_GET or $_COOKIES
>>(forgot the last one)
>
>
> $_REQUEST ?
>

$_REQUEST is just a synonym for both $_POST and $_GET. But I don't use
it - it's too easy for a hacker to substitute $_POST values in the $_GET
request.

If I want the form to be posted, I always use $_POST.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Sanders Kaufman wrote:
> Jerry Stuckle wrote:
>
>> Sanders Kaufman wrote:
>
>
>>> One more thing - on the session token.
>>> I notice that PHP puts it in the query string.
>>> Is it possible to force that into a cookie?
>>>
>>> I know this will mess with folks who turn cookies off, but I'm
>>> accounting for that elsehow.
>>
>>
>> PHP can put it in a cookie if the user has cookies enabled. This is
>> controlled by the session.use_cookies and session.use_only_cookie in
>> your php.ini file.
>
>
> I would need my app to handle that gracefully. Is there a built-in
> function to programatically determine which way it's set?

You could use ini_get() to check on it. But your server should be set up
to use cookies if they're available, and the query string if they're not.

And if the server isn't set up properly, it's time to get a new host,
IMHO. There are too many out there to worry about trying to get around
problems such as this.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

no@emails.thx wrote:
> On Wed, 06 Dec 2006 04:04:21 GMT, Sanders Kaufman <bucky@kaufman.net>
> wrote:
>
>
>>Jerry Stuckle wrote:
>>
>>>Sanders Kaufman wrote:
>>
>>>>If not - then the whole security issue is resolved by using $_GET and
>>>>$_POST correctly, right?
>>>
>>>Yes, you can use $_GET and $_POST (and $_SESSION). And if you leave
>>>register_globals off, then you *must* use them. Less chance for error.
>>
>>So - as long as I explicitly reference $_SESSION[] when continuing a
>>session, I'm not subject to the security vulnerabilities of
>>register_globals, right?
>
>
> If it is possible to switch register_globals OFF I would very strongly
> recommend it. Most hosting companies will have the ability to switch
> it on/off per domain or server and it will be much better for
> peace-of-mind of you get it switched off.
>
> I recently had a problem when the site that I had been working on
> in-house started coming up with all kinds of problems when it was run
> on the 'proper', commercial host. Turned out that register_globals was
> on, even though they were running PHP4.3 (nice eh?!) and I had session
> variables like $_SESSION['userid'] and later in my code I had used
> what I assumed would be local variables like $userid ... and of course
> they were the same thing and were corrupting each other! Grrr Turning
> register_globals off for that domain fixed the problem immediately.
>
>
>>One more thing - on the session token.
>>I notice that PHP puts it in the query string.
>>Is it possible to force that into a cookie?
>
>
> This is another configuration issue that you should be able to discuss
> with your host.
>
> Chris R.

Chris,

I make it even easier. I won't host with a company which has
register_globals enabled. And I tell them why I'm switching.

After all - if they don't understand the security risk (or don't care
about it), I don't know what other security gaps they might have. It's
a big red flag, IMHO.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Message-ID: <j6adnfNeKZPAdOvYnZ2dnUVZ_vWdnZ2d@comcast.com> from Jerry
Stuckle contained the following:

>>>
>>>doesn't cause an error of $MyVar hasn't been explicitly assigned a value
>>>in your code, but it is in the $_SESSION, $_POST, $_GET or $_COOKIES
>>>(forgot the last one)
>>
>>
>> $_REQUEST ?
>>
>
>$_REQUEST is just a synonym for both $_POST and $_GET. But I don't use
>it - it's too easy for a hacker to substitute $_POST values in the $_GET
>request.
>
>If I want the form to be posted, I always use $_POST.

Me too. I was just offering that as a suggestion for one you forgot

--
Geoff Berrow (put thecat out to email)
It's only Usenet, no one dies.
My opinions, not the committee's, mine.
Simple RFDs http://www.ckdog.co.uk/rfdmaker/