Forums | MacLife

Thanks for the info!

The $_REQUEST thing works and is a nice quick fix, but I would like to get my Apache configured so I can use variables normally.

I set 'AllowOverride All' in my httpd.conf and added a .htaccess file containing 'php_flag register_globals on' in my Sites folder. Still no luck.

How can I turn register globals back on? I'm behind a firewall, so I'm not concerned with security on my local machine.

You can configure PHP to register globals but there are very good reasons to leave it off and develop without.

1) All new versions of PHP will default to register globals off, and most hosting providers will leave it off. This means that if you develop a site that assumes register globals is on, then when the server is updated, you will have to update your code. It makes more sense to develop it now in a way that will not need to be updated.

2) Register globals presents a serious security hole, that a firewall does not protect. This is from the PHP.net website, security section:

One feature of PHP that can be used to enhance security is configuring PHP with register_globals = off. By turning off the ability for any user-submitted variable to be injected into PHP code, you can reduce the amount of variable poisoning a potential attacker may inflict. They will have to take the additional time to forge submissions, and your     internal variables are effectively isolated from user submitted data.   

While it does slightly increase the amount of effort required to work with PHP, it has been argued that the benefits far outweigh the effort.

The import_request_variable() function will accomplish the samething as register globals and if used correctly, is far more secure than register globals, but you do still have the possibility of variable poisoning.

I see. That is really nice to know.

I have been using eregi to make sure referer matches my domain before it does anything with passed vars.

That won't help you with the hole, as the data will still be passed from your page.

For example, you have a page:

login.php

Suppose that page uses in it a variable called $auth_ok which is unset and some sort of routine is used to verify a user and switches $auth_ok to true allowing access. If someone were to simply add:

login.php?auth_ok=1

That would allow access.  And the referer is still your site.  Not a likely example, but an illustrative one.

In fact any variable in your page could be set or tweaked (at the start) by simply adding it to the url string.  Turning that off seperates your internal variables from passed ones.  It simply means that no variable can be inserted by the user without you taking action.

Is it a huge security risk?  No, not a huge one.  But it depends on your code (or someone elses if you use something pre built.)  A clean coder wouldn't leave holes like that.  But a clean coder would also take advantage of barriers like that.  Malicious idiots are creative,  I rather plug a small potential hole than clean up the mess later.

I've tried to hack it myself to be sure, and didn't have any success (and I know all the var names). My 'security' portion of the script checks for referrer every time, so 0/1 will be reset even if they figured out the correct variable name and typed it into the address bar.

Falsifing a referrer is easy enough to do.  That is the point of having the request globals off, it puts control into the hands of the script not the client side.

...but what's the alternative to opening up a security hole? I need to move data from page to page. I guess I could make import_request_variables conditional. ...or do you suggest just using $_REQUEST, etc. only on the variables I need?

$_COOKIE['var_name'], $_POST['var_name'], $_GET['var_name'], etc...
it the safest way.  But it using the import_request_variables with prefix it safe as well because you are isolating request vars.
So:
import_request_variables("gpc", "incoming_");

login.php?user=me

becomes:

$incoming_user  in the script.

But really, careful coding is the best security.  Out of habit, I always set every variable I use first, and scrub all user input.  So the global setting of varibles won't affect my scripts, but it is always good to have multiple levels of security.