Forum Moderators: coopster

Message Too Old, No Replies

Grrrr! My host moved to register_globals ON

.... and without notice.

         

tomda

10:11 am on Sep 6, 2004 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Hi,

After uploading my last work and doing some test, I noticed that things were not like before (such as getting a the submit value in my URL - &submit='%20%20GO%20%20 - or being able to login just by typing username=me in the URL bar of the log in page).

Indeed, my host is now register_globals ON. I am not sure why they have made this move (from OFF to ON) but they should at least inform us.

Need to modify my htaccess files:
php_flag register_globals off.

coopster

12:31 pm on Sep 6, 2004 (gmt 0)

WebmasterWorld Administrator 10+ Year Member



I run into the same situation once in awhile. I give my recommendations, then setup an .htaccess file as you have done. What can you do? Best regards -- coopster

vincevincevince

2:05 pm on Sep 6, 2004 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



The submit value in the URL is not dependant upon register_globals, the other one is.

I recommend you find another host which takes security seriously.

mincklerstraat

4:20 pm on Sep 6, 2004 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



with the 'submit' thing, you might try monkeying with magic_quotes_gpc stuff - check the php manual on magic_quotes_gpc(), very likely that was changed at the same time as register globals. You might also check out urldecode() while you're at it for all that %20 stuff, that might get you what you want.

Good luck finding a host with register globals off - this could be pretty difficult. There are so many scripts that still register globals on that very few shared hosts will have it off by default. The .htaccess method then is the way to go (as well as just plain good coding and making sure you declare your variables, in which case you're safe anyways - but register globals off is a very nice extra precaution).

jatar_k

5:03 pm on Sep 6, 2004 (gmt 0)

WebmasterWorld Administrator 10+ Year Member



>> being able to login just by typing username=me in the URL bar of the log in page

that sounds more like you aren't testing your variables properly.

I agree I would speak to the host and if they don't take the concerns seriously then switch but....

A host switching to globals on shouldn't change anything. If all your vars are properly tested and you don't use $_REQUEST or extract() then it shouldn't matter.

You could also use this as an opportunity to secure your scripts and learn what things need to be addressed to work in both scenarios.

tomda

6:33 am on Sep 7, 2004 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



php_flag register_globals off gives me an internal error.
As it is a shared server and that I can not have access to php.ini, I will contact the host to find out if they are planning to move to GLOBAL off (may be when they will move to PHP 4.2). Because, I script on localhost with GLOBAL OFF and my codes are clean and variables are all tested, I think I can just wait a bit and be patient...

Vince_, you are right the submit value in the URL is not dependant upon register_globals, it is just that I had in the form tag action='#' so the URL was taking all values sent by the form.

Jatar_K, thanks for the advice and I do not use $_REQUEST or extract(), ouf! $_GET and $_POST are not the same than $_REQUEST? Correct me if I am wrong? I always use this script to get a variable


if(isset($_GET["var"])) {$var=$_GET["var"];} else {$var="0";}

Regarding the username problem, I had to change the value of the login form to usernameb. It seems that when submitting the form, my session_username (guest) were automatically updated by the value of the form. Such conflict between session and form variables is typical from having GLOBAL ON, is it?

CU

jatar_k

4:15 pm on Sep 7, 2004 (gmt 0)

WebmasterWorld Administrator 10+ Year Member



the reason $_REQUEST is a problem is this

Variables provided to the script via the GET, POST, and COOKIE input mechanisms, and which therefore cannot be trusted. The presence and order of variable inclusion in this array is defined according to the PHP variables_order configuration directive.

GET can override POST and corrupt your vars.

>> uch conflict between session and form variables is typical from having GLOBAL ON, is it?

I wouldn't think so if you are getting them all specifically.