Writing secure scripts with PHP 4.2_PHP Tutorial

Original work: Kevin Yank Reposted from: www.linuxforum.net (Congratulations on opening this again)

For a long time, one of the biggest selling points of PHP as a server-side scripting language was that it would automatically update the values ​​submitted from the form. Create a global variable. In PHP 4.1, the PHP creators recommended an alternative means of accessing submitted data. In PHP 4.2, they did away with that old practice! As I will explain in this article, the purpose of making such a change is for security reasons. We'll look at new ways PHP handles form submissions and other data, and explain why doing so will make your code more secure.

What’s wrong here?

Look at the following PHP script, which is used to authorize access to a web page when the entered username and password are correct:
// Check username and password
if ($username == 'kevin' and $password == 'secret')
$authorized = true;
?>

Please enter your username and password:

Username:

Password:

< /form>



OK, I believe that about half of the readers will say with disdain, "That's stupid - I wouldn't make such a mistake!" But I guarantee that there are many readers who will think, "Hey, no problem, I will write like this too!" Of course there will be a few people who will be confused by this question ("What is PHP?"). PHP is designed to be a "good and easy" scripting language that beginners can learn to use in a short time; it should also prevent beginners from making the above mistakes.
Going back to the previous question, the problem with the above code is that you can easily gain access without providing the correct username and password. Just add ?authorized=1 at the end of your browser's address bar. Because PHP automatically creates a variable for every submitted value -- whether from a form submission, a URL query string, or a cookie -- this will set $authorized to 1, so an unauthorized user can Security restrictions can be exceeded.
So, how to simply solve this problem? Just set $authorized to false by default at the beginning of the program. This problem no longer exists! $authorized is a variable created entirely in program code; but why should a developer have to worry about every malicious user-submitted variable?

What changes have been made in PHP 4.2?

In PHP 4.2, the register_globals option in newly installed PHP is turned off by default, so the EGPCS value (EGPCS is the abbreviation of Environment, Get, Post, Cookies, Server - This is the source of external variables in PHP full scope) will not be created as global variables. Of course, this option can also be turned on manually, but PHP developers recommend that you turn it off. To implement their intent, you need to use other methods to obtain these values.
Starting from PHP 4.1, the EGPCS value can be obtained from a specified set of arrays:
$_ENV -- Contains system environment variables
$_GET -- Contains variables in the query string, and submission method Variables in the GET form
$_POST -- Contains variables in the form submitted as POST
$_COOKIE -- Contains all cookie variables
$_SERVER -- Contains server variables, such as HTTP_USER_AGENT
$_REQUEST -- Contains the entire contents of $_GET, $_POST and $_COOKIE
$_SESSION -- Contains all registered session variables
Before PHP 4.1, when the developer turned off the register_globals option (this was also considered (as a way to improve PHP performance), you have to use nasty names like $HTTP_GET_VARS to get these variables. Not only are these new variable names shorter, but they also have other advantages.
First, let’s rewrite the code mentioned above in PHP 4.2 (which means turning off the register_globals option):
$username = $_REQUEST['username'];
$password = $_REQUEST['password'];

// Check username and password
if ($username == 'kevin' and $password == 'secret')
$authorized = true;
?>

Please enter your username and password:

Username :

Password:

As you can see, all I need to do is add the following two lines at the beginning of the code:
$username = $ _REQUEST['username'];
$password = $_REQUEST['password'];
Because we want the username and password to be submitted by the user, we get these values ​​from the $_REQUEST array. Using this array allows the user to freely choose the delivery method: through a URL query string (for example, allowing users to automatically enter their credentials when creating a bookmark), through a form submission, or through a cookie. If you want to restrict certificate submission to only via forms (more precisely, via HTTP POST requests), you can use the $_POST array:
$username = $_POST['username'];
$password = $_POST['password'];
Except for "introducing" these two variables, there is no change in the program code. Simply turning off the register_globals option forces developers to better understand which data is coming from external (untrusted) sources.
Please note that there is a small problem here: the default error_reporting setting in PHP is still E_ALL & ~E_NOTICE, so if the two values ​​​​of "username" and "password" have not been submitted, trying to get the value from the $_REQUEST array or $_POST Obtaining these two values ​​​​in the array does not incur any error messages. If your PHP program needs strict error checking, you will also need to add some code to check these variables first.

But does this mean more input?

Yes, in simple programs like the above, using PHP 4.2 often increases the amount of typing. But let’s look on the bright side – your program is safer after all!
But seriously, the designers of PHP did not completely ignore your pain. These new arrays have a special feature that no other PHP variable has, they are completely global variables. How does this help you? Let's first expand on our example.
In order to enable multiple pages in the site to use username/password arguments, we write our user authentication program into an include file (protectme.php):
function authorize_user($authuser, $authpass)
{
$username = $_POST['username'];
$password = $_POST['password'];
// Check username and password
if ($username != $authuser or $password != $authpass):
?>

Very simple and clear, right? Now it’s time to test your eyesight and experience – what’s missing in the authorize_user function?
$_POST is not declared as a global variable in the function! In php 4.0, when register_globals is turned on, you need to add a line of code to get the $username and $password variables in the function:
function authorize_user($authuser, $authpass)
{
global $username, $password;
...
In PHP, unlike other languages ​​with similar syntax, variables outside functions are not automatically available in functions. You need to add a line as explained above to specify where they come from. global scope.
In PHP 4.0, when register_globals is turned off to provide security, you can use the $HTTP_POST_VARS array to obtain the values ​​submitted by your form, but you still need to import this array from the global scope:
function authorize_user($ authuser, $authpass)
{
global $HTTP_POST_VARS;
$username = $HTTP_POST_VARS['username'];
$password = $HTTP_POST_VARS['password'];
But in PHP In versions 4.1 and later, the special $_POST variable (and the others mentioned above) can be used in all scopes. This is why there is no need to declare the $_POST variable as a global variable in the function:
function authorize_user($authuser, $authpass)
{
$username = $_POST['username'];
$password = $_POST['password'];

What impact does this have on the session?

The introduction of the special $_SESSION array actually helps simplify the session code. Instead of declaring session variables as global variables and then keeping track of which variables are registered, you can now simply reference all your session variables from $_SESSION['varname'].
Now let’s look at another example of user authentication. This time, we use sessions to indicate that a user who continues to stay on your site has been authenticated. First, let’s take a look at the PHP 4.0 version (enable register_globals):
session_start();
if ($username == 'kevin' and $password == 'secret')
{
$authorized = true;
session_register('authorized');
}
?>





Similar to the initial program, this program also has security vulnerabilities. Adding ?authorized=1 at the end of the URL can bypass security measures and directly access the page content. Developers can treat $authorized as a session variable and ignore that the same variable can easily be set via user input.
After we add our special array (PHP 4.1) and turn off register_globals (PHP 4.2), our program will look like this:
session_start();
if ($username == 'kevin' and $password == 'secret')
$_SESSION['authorized'] = true;
?>





Is it simpler? You no longer need to register a normal variable as a session variable, you just need to set the session variable directly (in the $_SESSION array) and use it in the same way. Programs are shorter and there is less confusion about what variables are session variables!

Summary

In this article, I explained the underlying reasons for the changes to the PHP scripting language. In PHP 4.1, a special set of data was added to access external data. These arrays can be called in any scope, which makes access to external data more convenient. In PHP 4.2, register_globals is turned off by default to encourage the use of these arrays to prevent inexperienced developers from writing unsafe PHP code.

http://www.bkjia.com/PHPjc/314671.htmlwww.bkjia.comtruehttp: //www.bkjia.com/PHPjc/314671.htmlTechArticleOriginal work: Kevin Yank Reprinted from: www.linuxforum.net (Congratulations on opening this again) For a long time, PHP One of the biggest selling points of a server-side scripting language is that values ​​submitted from forms are automatically generated...