|
|
Posted by no on 12/06/06 10:52
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.
Navigation:
[Reply to this message]
|