$ _ Request ['globals'] in PHP and how to handle the global variable Vulnerability

As we all know, when register_globals = on in PHP. ini, various variables are injected with code, such as request variables from HTML forms. In addition, PHP does not require initialization before using variables. This may cause insecurity. If someone maliciously sends such a GET request "http: // yourdomain/unsafe. php? Globals = ", then the value of the $ globals variable is cleared, resulting in insecurity. So we can write it like this.

[PHP]
If (isset ($ _ request ['globals'])
Or isset ($ _ FILES ['globals'])
And ini_get ('register _ globals ')){
Die (globals overwrite attempted .');
}

[/PHP]

======================================

Register_globals is a configuration in PHP. ini. This configuration affects how PHP receives passed parameters. If your question is: Why cannot my form transmit data? Why can't my program get the passed variables? Wait, so you need to carefully read the following content.

The value of register_globals can be set to: On or off. Let's take a piece of code to describe their differences.

Code:

<Form name = "frmtest" id = "frmtest" Action = "url"> <Input type = "text" name = "user_name" id = "user_name"> <Input type = "password" name = "user_pass" id = "user_pass"> <Input type = "Submit" value = "login"> </Form>

When register_globals = off, when receiving the next program, use $ _ Get ['user _ name'] and $ _ Get ['user _ pass'] to accept the passed values. (Note: when the method attribute of <form> is post, use $ _ post ['user _ name'] and $ _ post ['user _ pass']).

When register_globals = on, the next program can directly use $ user_name and $ user_pass to accept the value.

As the name implies, register_globals means registration as a global variable. Therefore, when on, the passed value will be directly registered as a global variable for use, and when off, we need to get it in a specific array. Therefore, if you encounter the above problems that cannot get the value, you should first check whether your register_globals settings match the method you get the value. (You can use the phpinfo () function or directly view PHP. ini)

So why should we use off? There are two reasons:
1. php later versions use off by default. Although you can set it to on, when you cannot control the server, the compatibility of your code becomes a major problem, you 'd better start programming with the off style from now on
2. Here are two articles to explain why we should turn off instead of on.
Http://www.linuxforum.net/forum/gshowflat.php? Cat = & board = php3 & number = 292803 & page = 0 & view = collapsed & SB = 5 & O = All & fpart =
Http://www.php.net/manual/en/security.registerglobals.php

Another question is, What should I do if I used to write a large number of scripts in the on style?
If your previous scripts are well planned, there is a public inclusion file, such as config. inc. for PHP files, add the following code in the file to simulate it (this code does not guarantee that 100% can solve your problem, because I did not perform a lot of tests, but I think it works well ). In addition, the solution in this post can also refer to (http://www.chinaunix.net/forum/viewtopic.php? T = 159284 ).

Code:

<? PHP If (! Ini_get ('register _ globals ')) { Extract ($ _ post ); Extract ($ _ Get ); Extract ($ _ server ); Extract ($ _ files ); Extract ($ _ env ); Extract ($ _ cookie ); If (isset ($ _ Session )) { Extract ($ _ session ); } } ?>

Register_globals = off not only affects how to obtain data transmitted from <form> and URL, but also affects session and cookie. The corresponding method for obtaining session and cookie should be: $ _ session [] and $ _ cookie. At the same time, session processing has also changed. For example, session_register () is unnecessary and invalid. For details about the changes, see session handling functions in PHP manual.

The content in the $ _ request is actually from $ _ get $ _ post $ _ cookie. The disadvantage is that the variable cannot be determined whether it comes from get post or cookie. It is not applicable to scenarios with strict requirements.