PHP development can not be contrary to the safety rules

As PHP programmers, especially novices, always know too little about the dangers of the Internet, for many of the external invasion are at a loss what to do, they do not know how hackers invaded, submitted to the invasion, upload vulnerabilities, sql Injection, cross-scripting and more. As a basic precaution you need to be aware of your external commits and do a good job with the first side of the security mechanism to handle the firewall.

Rule 1: Never trust external data or enter it

The first thing you must recognize about web application security is that you should not trust external data. External data includes any data that is not entered directly by the programmer in the PHP code. Any data from any other source (such as GET variables, form POSTs, databases, configuration files, session variables, or cookies) is untrusted until you take steps to ensure your security.

For example, the following data elements can be considered safe because they are set in PHP.

Listing 1. Code safe and secure

$ myUsername = 'tmyer';

$ arrayarrayUsers = array ('tmyer', 'tom', 'tommy');

define ("GREETING", 'hello there'. $ myUsername);

?>

However, the following data elements are flawed.

Listing 2. Unsafe, flawed code

$ myUsername = $ _POST ['username']; // tainted!

$ arrayarrayUsers = array ($ myUsername, 'tom', 'tommy'); // tainted!

define ("GREETING", 'hello there'. $ myUsername); // tainted!

?>

Why is the first variable $ myUsername flawed? Because it comes directly from the form POST. Users can enter any string in this input field, including malicious commands to clear files or run previously uploaded files. You might ask, "Can not I avoid this danger with a Javascrīpt form validation script that accepts only AZ?" Yes, it's always a good step, but as you will see later , Anyone can download any form to their own machine, modify it, and resubmit anything they need.

The solution is simple: You must run cleanup code on $ _POST ['username']. If you do not, then at any other time using $ myUsername, such as in arrays or constants, you can contaminate these objects. An easy way to clean up user input is to use a regular expression to handle it. In this example, I only want to accept letters. It may also be a good idea to limit the string to a specific number of characters or to require that all letters be lowercase.

Listing 3. Making user input safer

$ myUsername = cleanInput ($ _ POST ['username']); // clean!

$ arrayarrayUsers = array ($ myUsername, 'tom', 'tommy'); // clean!

define ("GREETING", 'hello there'. $ myUsername); // clean!

function cleanInput ($ input) {$ clean = strtolower ($ input);

$ clean = preg_replace ("/ [^ az] /", "", $ clean);

$ clean = substr ($ clean, 0,12); return $ clean;

}

?>

Rule 2: Disable PHP settings that make security difficult to implement

You already know that you can not trust user input, and you should know that you should not trust how to configure PHP on your machine. For example, make sure to disable register_globals. If register_globals is enabled, it's possible to do something careless, such as using $ variable to replace a GET or POST string of the same name. By disabling this setting, PHP forces you to reference the correct variable in the correct namespace. To use a variable from form POST, you should reference $ _POST ['variable']. This will not misinterpret this particular variable into a cookie, session, or GET variable.

Rule 3: If you can not understand it, you can not protect it

Some developers use strange syntax, or the statement is very compact, forming a brief but vague code. This approach can be very efficient, but you can not decide how to protect it if you do not understand what the code is doing. For example, which of the following two sections of code do you like?

In the second clearer code snippet, it is easy to see that $ input is flawed, needs to be cleaned up, and then safely handled.

Rule 4: "Defense in Depth" is a new magic weapon

This tutorial uses examples to illustrate how to protect online forms and take the necessary steps in the PHP code that handles forms. Similarly, you can still take steps to ensure that your SQL queries use escaped user input, even when using PHP regex to ensure that the GET variables are completely numeric. Defense in depth is not just a good idea, it ensures you do not get into serious trouble. Now that the basic rules have been discussed, let's look at the first threat: SQL injection attacks.

◆ prevent SQL injection attacks

In a SQL injection attack, the user adds information to the database query by manipulating the form or by using a GET query string. For example, suppose you have a simple login database. Each record in this database has a username field and a password field. Build a login form that lets users log in.