Causes and Prevention of PHP program vulnerabilities

Misuse include

1. cause:

Include is the most common function for compiling PHP websites and supports relative paths. Many PHP scripts directly use an input variable as an Include parameter, resulting in arbitrary reference scripts, absolute path leakage, and other vulnerabilities. See the following code:

...

$ Includepage = $ _ GET ["includepage"];

Include ($ shortdepage );

...

Obviously, we only need to submit different Includepage variables to get the desired page. If you submit a page that does not exist, you can make the PHP Script Error and leak the actual absolute path (the solution to this problem is described in the following article ).

2. Vulnerability Resolution:

The solution to this vulnerability is to determine whether the page exists and then Include it. Or, more strictly, use arrays to specify the files that can be included. See the following code:

$ Pagelist = array ("test1.php", "test2.php", "test3.php"); // files that can be included are specified here

If (isset ($ _ GET ["includepage"]) // checks whether $ includepage exists.

{

$ Includepage = $ _ GET ["includepage"];

Foreach ($ pagelist as $ prepage)

{

If ($ includepage = $ prepage) // check whether the file is in the allowed list

{

Include ($ prepage );

$ Checkfind = true;

Break;

}

}

If ($ checkfind = true) {unset ($ checkfind );}

Else {die ("invalid reference page! ");}

}

In this way, the problem can be solved well.

TIPS: Functions with this problem include: require (), require_once (), include_once (), readfile (), and so on. Pay attention to this when writing.

Input variables are not filtered.

1. cause:

This vulnerability appeared in ASP as early as possible, resulting in countless injection vulnerabilities. However, since PHP was less influential at the time, not many people can pay attention to this. For PHP, this vulnerability has a greater impact than ASP, because many PHP scripts are used in text-based databases. Of course, there are also SQL statement injection problems. For a classic example, the first is the database:

$ Id = $ _ GET ["id"];

$ Query = "SELECT * FROM my_table where id =". $ id. ""; // classic SQL Injection Vulnerability

$ Result = mysql_query ($ query );

It is obvious that we can use injection to obtain other contents of the database. I will not describe it in detail here. It is the same as ASP injection. You can refer to the previous anti-DDoS pro. Then let's look at the text database:

$ Text1 = $ _ POST ["text1"];

$ Text2 = $ _ POST ["text2"];

$ Text3 = $ _ POST ["text3"];

$ Fd = fopen ("test. php", "");

Fwrite ($ fd, "$ text1 & line; $ text2 & line; $ text3 ");

Fclose ($ fd );

Text vulnerabilities can be said to be more serious. If we insert a small PHP code into the submitted variable, we can change the text database test. php into a PHP backdoor. Even Insert the upload code so that we can upload a complete PHP backdoor. Then raise the permission, and the server is yours.

2. Vulnerability Resolution:

The solution to this vulnerability is to strictly filter all submitted variables. Replace sensitive characters. We can use the htmlspecialchars () function provided by PHP to replace HTML content. Here is an example:

// Construct a filter function

Function flt_tags ($ text)

{

$ Badwords = array ("fuck your mom", "fuck"); // vocabulary filtering list

$ Text = rtrim ($ text );

Foreach ($ badwords as $ badword) // filter words here

{

If (stristr ($ text, $ badword) = true) {die ("error: Your submitted content contains sensitive words. Please do not submit sensitive content. ");}

}

$ Text = htmlspecialchars ($ text); // replace HTML

// Replace the carriage return

$ Text = str_replace ("", "", $ text );

$ Text = str_replace ("", "", $ text );

$ Text = str_replace ("& line;", "│", $ text); // Replace text database separator "& line;" with "│"

$ Text = preg_replace ("/s {2}/", "", $ text); // replace Spaces

$ Text = preg_replace ("//", "", $ text); // replace with a space

If (get_magic_quotes_gpc () {$ text = stripslashes ($ text);} // if magic_quotes is enabled, replace

Return $ text;

}

$ Text1 = $ _ POST ["text1"];

$ Text2 = $ _ POST ["text2"];

$ Text3 = $ _ POST ["text3"];

// Filter all input

$ Text1 = flt_tags ($ text1 );

$ Text2 = flt_tags ($ text2 );

$ Text3 = flt_tags ($ text3 );

$ Fd = fopen ("test. php", "");

Fwrite ($ fd, "$ text1 & line; $ text2 & line; $ text3 ");

Fclose ($ fd );

After some replacement and filtering, you can safely write data into the text or database.

Incomplete judgment by the Administrator

1. cause:

We use PHP to write scripts, which usually involves administrator permissions. Some scripts only make "yes" judgments on administrator permissions, and often ignore "no" judgments. When register_globals is enabled in the PHP configuration file (it is disabled by default in Versions later than 4.2.0, but many people open it for convenience, which is extremely dangerous ), you can submit variables to impersonate administrators. Let's take a look at the example code:

$ Cookiesign = "admincookiesign"; // determine whether the cookie variable is Admin.

$ Adminsign = $ _ COOKIE ["sign"]; // get your cookie variable

If ($ adminsign = $ cookiesign)

{

$ Admin = true;

}

If ($ admin) {echo "is in the administrator state. ";}

It looks safe, huh, huh. Now let's assume that register_globals in the PHP configuration file is open. We submit the address "test. php? Admin = true ", is the result displayed? Although we do not have the correct Cookie, because register_globals is enabled, the admin variable we submitted is automatically registered as true. In addition, the script lacks the "no" judgment, so that we can smoothly obtain the Administrator permission through admin = true. This problem exists in most websites and forums.

2. Vulnerability Resolution:

To solve this problem, we only need to add "no" to the administrator in the script. We still assume that register_globals in the PHP configuration file is open. The Code is as follows:

$ Cookiesign = "admincookiesign"; // determine whether the cookie variable is Admin.

$ Adminsign = $ _ COOKIE ["sign"]; // get your cookie variable

If ($ adminsign = $ cookiesign)

{

$ Admin = true;

}

Else

{

$ Admin = false;

}

If ($ admin) {echo "is in the administrator state. ";}

In this way, even if the attacker submits the variable admin = true without the correct Cookie, the script will set $ admin to False in future judgment. In this way, some problems are solved. However, because $ admin is a variable, if a vulnerability occurs in other script references in the future, the value of $ admin will be assigned again, causing a new crisis. Therefore, we should use constants to store the determination of administrator permissions. Use the Define () statement to Define an admin constant to record administrator permissions. If the assignment is assigned with a duplicate value, an error occurs. This protects your account. See the following code:

$ Cookiesign = "admincookiesign"; // determine whether the cookie variable is Admin.

$ Adminsign = $ _ COOKIE ["sign"]; // get your cookie variable

If ($ adminsign = $ cookiesign)

{

Define (admin, true );

}

Else

{

Define (admin, false );

}

If (admin) {echo "is in the administrator state. ";}

It is worth noting that we use the Define statement, so when calling the Admin constant, do not habitually Add the variable symbol $, but use Admin and! Admin.

Text Database exposure

1. cause:

As mentioned above, text databases are flexible and do not require any external support. In addition, PHP has powerful file processing capabilities. Therefore, text databases are widely used in PHP scripts. There are even a few good forum programs that use text databases. However, the security of text databases is lower than that of other databases.

2. Vulnerability Resolution:

As a common file, a text database can be downloaded, just like MDB. Therefore, we need to protect MDB to protect text databases. Change the suffix of the text database to. PHP. And add it to the first row of the database. In this way, the text database will act as a PHP file and exit the execution on the first line. That is, an empty page is returned to protect the text database.

Incorrect path Leakage

1. cause:

When PHP encounters an error, it will give the location, number of rows, and cause of the error script, for example:

Notice: Use of undefined constant test-assumed test in D: interpubigflyest. php on line 3

Many people say that this is no big deal. However, the consequences of leaking the actual path are unimaginable. For some intruders, this information is very important. In fact, many servers have this problem.

Some network administrators simply set display_errors in the PHP configuration file to Off, but I think this method is too negative. Sometimes, we do need PHP to return an error message for debugging. In addition, when an error occurs, you may need to give the user an explanation, or even navigate to another page.

2. Vulnerability Resolution:

PHP has provided the set_error_handler () function for customizing error handling handles since 4.1.0, but few script writers know it. In many PHP forums, I have seen only a small number of cases. Set_error_handler is used as follows:

String set_error_handler (callback error_handler [, int error_types])

Now we can use custom error handling to filter out the actual path.

// Identify admin as the administrator. true is the administrator.

// The custom error handler must have these four input variables $ errno, $ errstr, $ errfile, and $ errline. Otherwise, the error handler is invalid.

Function my_error_handler ($ errno, $ errstr, $ errfile, $ errline)

{

// Filter the actual path if it is not an administrator

If (! Admin)

{

$ Errfile = str_replace (getcwd (), "", $ errfile );

$ Errstr = str_replace (getcwd (), "", $ errstr );

}

Switch ($ errno)

{

Ca