Four rules for ensuring the security of PHP applications (1) _ PHP Tutorial

Four rules for ensuring the security of PHP applications (1 ). Rule 1: never trust external data or enter information about Web application security. The first thing that must be realized is that you should not trust external data. External data (outsidedata) includes Rule 1: never trust external data or input

The first thing that must be realized about Web application security is that external data should not be trusted. External data includes any data that is not directly input by programmers in PHP code. Before taking measures to ensure security, any data from any other source (such as GET variables, form POST, database, configuration file, session variables, or cookies) is untrusted.
For example, the following data elements can be considered safe because they are set in PHP.

Listing 1. safe and flawless code

＜?php$myUsername = 'tmyer';$arrayUsers = array('tmyer', 'tom', 'tommy');define("GREETING", 'hello there' . $myUsername);?＞

However, the following data elements are flawed.

List 2. insecure and defective code

＜?php$myUsername = $_POST['username']; $arrayUsers = array($myUsername, 'tom', 'tommy'); define("GREETING", 'hello there' . $myUsername); ?＞

Why is the first variable $ myUsername defective? Because it is directly from form POST. You can enter any strings in this input field, including malicious commands used to clear files or run previously uploaded files. You might ask, "isn't it possible to avoid this risk using a client that only accepts letters of A-Z (Javascr into pt) form validation script ?" Yes, this is always a good step, but as you will see later,

Anyone can download any form to their machine, modify it, and resubmit anything they need.
The solution is simple: you must run the cleanup code on $ _ POST ['username. Otherwise, $ myUsername may be contaminated at any other time (such as in an array or constant.

A simple method for clearing user input is to use a regular expression to process it. In this example, only letters are allowed. It may be a good idea to limit a string to a specific number of characters, or to require that all letters be in lowercase.

Listing 3. making user input secure

＜?PHP$myUsername = cleanInput($_POST['username']); //clean!$arrayUsers = array($myUsername, 'tom', 'tommy'); //clean!define("GREETING", 'hello there' . $myUsername); //clean!function cleanInput($input){ $clean = strtolower($input); $clean = preg_replace("/[^a-z]/", "", $clean); $clean = substr($clean,0,12); return $clean;}?＞

Rule 2: disable PHP settings that make security difficult

You already know that you cannot trust user input. you should also know that you should not trust the PHP configuration method on the machine. For example, make sure to disable register_globals. If register_globals is enabled, you may do some careless things, such as replacing the GET or POST string with the same name with $ variable. By disabling this setting, PHP forces you to reference the correct variables in the correct namespace. To use a variable from Form POST, you should reference $ _ POST ['variable']. In this way, the specific variable will not be misunderstood as a cookie, session, or GET variable.

Rule 3: If you cannot understand it, you cannot protect it.

Some developers use strange syntaxes, or organize statements very compact to form short but ambiguous code. This method may be highly efficient, but if you do not understand what the code is doing, you cannot decide how to protect it.

For example, which of the following two sections of code do you like?

Listing 4. easy code protection

＜?PHP //obfuscated code$input = (isset($_POST['username']) ? $_POST['username']:'');//unobfuscated code$input = '';if (isset($_POST['username'])){ $input = $_POST['username'];}else{ $input = '';}?＞

In the second clear code segment, it is easy to see that $ input is defective and needs to be cleaned up before it can be processed safely.

Rule 4: "defense in depth" is a new magic weapon

This tutorial uses examples to illustrate how to protect online forms and take necessary measures in PHP code that processes forms. Similarly, even if PHP regex is used to ensure that the GET variable is completely numeric, you can still take measures to ensure that the SQL query uses escape user input.

Defense in depth is not just a good idea. it ensures that you are not in serious trouble.

Now that we have discussed the basic rules, we will study the first one.

Threat: SQL injection attacks.

Prevent SQL injection attacks

In SQL injection attacks, you can manipulate the form or GET query string to add information to the database query. For example, assume there is a simple login database. Each record in this database has a username field and a password field. Create a logon form to allow users to log on.

Listing 5. simple logon form

＜html＞＜head＞＜title＞Login＜/title＞＜/head＞＜body＞＜form action="verify.PHP" method="post"＞＜p＞＜label for='user'＞Username＜/label＞＜input type='text' name='user' id='user'/＞＜/p＞＜p＞＜label for='pw'＞Password＜/label＞＜input type='password' name='pw' id='pw'/＞＜/p＞＜p＞＜input type='submit' value='login'/＞＜/p＞＜/form＞＜/body＞＜/html＞

This form accepts the user name and password entered by the user, and submits the user input to the file verify. php. In this file, PHP processes data from the login form, as shown below:

1

Tip 1: do not trust external data or enter information about Web application security. The first thing you must realize is that you should not trust external data. External data (outside data) includes...