Original: Shaun Clows Translation: AnalysisT Translation This article is because the articles about CGI security are taken as examples, while there are few articles that specifically describe ASP, PHP or JSP security. This article of Shaun Clowes is more comprehensive in the security issues of PHP, and the original text can be found in http://www.securereality.com.au/studyinscarlet.txt. Since the original text is relatively long, and a considerable part is the basic knowledge of the background or PHP of the article, it does not involve PHP security, so I have no translation. If you want to know about this, please refer to the original text. The article mainly analyzes the security of PHP from global variables, remote files, file uploads, library files, session files, data types, and easy error-in functions, and some useful advice on how to enhance PHP security . Ok, talk less, we are justified! [Global Variables] Variables in PHP do not require prior notes, they will automatically create during the first use, and their types do not need to be specified, they will automatically determine according to the context environment. From a programmer's perspective, this is undoubtedly an extremely convenient processing method. Obviously, this is also a very useful feature of rapid development of languages. Once a variable is created, you can use anywhere in the program. The result of this feature is that the programmer rarely initializes the variable. After all, when they created the first time, they are empty. Obviously, the main function of PHP-based applications is generally accepted by users (mainly form variables, upload files, and cookie, then process the input data, and then return the results to the client browser. In order to enable the PHP code to access the user's input as easy, PHP is actually handled by these input data as global variables. E.g:
Obviously, this will display a text box and submit button. When the user clicks on the commit button, "Test.php" handles the user's input, when "Test.php" is running, "$ Hello" will contain the data entered in the text box. From here we should see that an attacker can create any global variables in accordance with their own will. If the attacker does not call "Test.php" through the form input, but enter http: //server/test.php? Hello = hi & setup = no directly in the browser address bar, then, not only "$ Hello" is created "$ Setup" is also created. Translator Note: These two methods are also what we usually say "POST" and "GET" methods. The following user authentication code exposes security issues caused by the global variable of PHP:
The above code first checks if the user's password is "Hello". If you match, set "$ auth" to "1", that is, by authentication. If "$ Suth" is "1", some important information will be displayed. The surface looks correct, and we have a considerable number of people doing this, but this code has made a mistake, it assumes that "$ auth" is empty when there is no set value, but does not think of an attacker You can create any global variables and assign values. Through similar "http://server/test.php? Auth = 1" method, we can completely deceive this code so that it believes that we have been certified. Therefore, in order to improve the security of the PHP program, we cannot believe any variables that are not clearly defined. This can be a very difficult task if there are many variables in the program. A commonly used protection is to check the variables in the array http_get [] or post_vars [], depending on our submissions (GET or POST). When the PHP is configured to open the "TRACK_VARS" option (this is the default value), the variable submitted by the user can be obtained in the total variable and the array mentioned above. However, it is worth explanating that PHP has four different array variables to process users' input. HTTP_GET_VARS array is used to process variables submitted by the GET method, and the http_post_vars array is used to process variables submitted by the POST mode, and the http_cookie_vars array is used to process variables submitted as a cookie header, and for http_post_files arrays (the new PHP is only available), it is completely An alternative way for users to submit variables. A user's request can easily put the variables in these four arrays, so a secure PHP program should check these four arrays. [Remote File] PHP is a language with rich feature, providing a large number of functions that make the programmer to implement a feature. However, from a safe point of view, the more functions, the harder it is, the harder it is, the remote file is a good example of this problem: / n ");?> The above script tries to open the file" $ FileName ", if the error message is displayed. It is obvious that if we can specify" $ filename ", you can use this script to browse any files in the system. However, this script still has a less obvious feature, that is It can read files from any other web or ftp site. In fact, most file processing functions of PHP are transparent to the processing of remote files. For example: "$ filename" http: // target / scripts / ..% c1% 1c ../ winnt / system32 / cmd.exe? / c DIR "The above code actually uses the Unicode vulnerability on the host Target, which enables the DIR command. This makes the INCLUDE supporting the remote file. ), Request (), include () more interesting in the context environment. These functions of these functions are the contents of the specified file, and they explain them according to the PHP code, mainly in the library file. For example, :
In the above example, "$ libdir" is typically a path that has already been set before executing the code. If the attacker can make the "$ libdir" not set, then he can change this path. But an attacker can't do anything because they can only access files.php in their specified path ("Poison Null Byte" attack in Perl has no effect on PHP). However, due to the support for remote files, attackers can do anything. For example, an attacker can put a file Languages.php on a server, including the following: and set "$ libdir" to "http: //
/ "In this way we can perform the above attack code on the target host, and the content of the" / etc "directory is returned to the customer's browser. Need to note that the attack server (that is, evilhost) should not perform PHP Code, otherwise the attack code will be in the attack server, not the target server, if you want to know the specific technical details, please refer to: http://www.secureRITY.com.au/sradv00006.txt [file upload] PHP automatic support Based on the RFC 1867 file upload, let's see the example below:
The above code allows the user to select a file from the local machine. When the submission is clicked, the file will be uploaded to the server. This is obviously a useful feature, but the php response method makes this function unsafe. When PHP receives this request, even before it starts parsing the called PHP code, it will accept the remote user's file, check if the length of the file exceeds the value defined by "$ max_file_size variable", if passing these If the file is tested, the file will be present in a local temporary directory. Therefore, an attacker can send any file to the host running the PHP, and the file has been put on the server when the PHP program has not decided to accept the file upload. Here I don't discuss the possibility of using the file upload to perform DOS attacks on the server. Let us consider the PHP program uploaded by the file. As we said above, the file is received and there is a server (where is specified in the configuration file, generally / TMP), the extension is generally random, similar "phpxuoxg "form. The PHP program needs to upload the file information to handle it, which can be used in two ways, one way is already used in PHP 3, and the other is introduced after we introduced the previous method. However, we can definitely say that problems still exist, most PHP programs are still using old way to process upload files. PHP sets four global variables to describe loading files, such as the above example: $ Hello = filename on local machine (eg "/ tmp / phpxxuoxg") $ hello_size = size in bytes of file (eg 1024) $ Hello_Name = the Original Name of the File on The Remote System (EG "C: //temp//hello.txt") $ Hello_TYPE = MIME TYPE OF UPLOADED File (eg "text / place") then PHP program start processing according to "$ Hello" The specified file is that "$ hello" is not necessarily a variable set for a PHP, and any remote user can specify it. If we use the following way: http://vulnhost/vuln.php? Hello = / etc / passwd & hello_size = 10240 & hello_type = text / plain & hello_name = hello.txt will result in the following PHP global variables (of course the post method can be (even Cookie): $ hello = "/ etc / passwd" $ hello_size = 10240 $ hello_type = "text / place" $ hello_name = "Hello.txt" The form data is just satisfied with the variables expected by the PHP program, but at this time The PHP program no longer processes the uploaded file, but processes "/ etc / passwd" (usually the content exposure). This kind of attack can be used to expose any sensitive file. I have already said in front, the new version of PHP uses http_post_files [] to determine upload, and also provide a lot of functions to solve this problem, such as a function to determine whether a file is not actually loaded. These functions solve this problem, but in fact, there are many PHP programs still use the old way, which is easy to receive this attack.
As a variant of the attack method uploaded, let's take a look at the following paragraph: If an attacker can control the "$ theme", it is clear that it can use "$ theme" to read any files on the remote system. The ultimate goal of the attacker is to perform any instructions on the remote server, but he can't use a remote file, so he must have a PHP file on the remote server. This seems that it seems that it is impossible, but the file is uploaded to help us. If the attacker first creates a file containing PHP code on the local machine, then create a form that contains the file domain named "theme" Finally, use this form to upload the code that the created PHP code is submitted to the above code via the file, and the PHP will save the file submitted by the attacker and set the "$ THEME" to the file submitted by the attacker. This file is checked, and the code of the attacker will also be executed. After obtaining the ability to perform any of the instructions, the attacker obviously wants to improve the permissions or expand the results, and this also requires some tool sets not on the server, and the file upload has helped us. Attackers can use file upload function to upload tools, put them on the server, then use the ability to perform instructions, use chmod () to change the permissions of the file, and then execute. For example: an attacker can bypass a local root attack program on a firewall or IDS, then execute, which is ROOT permission.
