How to attack common vulnerabilities in PHP programs (Part 2)

[Library File] As we discussed earlier, include() and require() are mainly to support the code library, because we usually put some frequently used functions into a separate file. This separate file It is the code library. When we need to use the functions in it, we only need to include this code library into the current file. Initially, when people developed and released PHP programs, in order to distinguish the code base from the main program code, they usually set an ".inc" extension for the code base file. However, they soon discovered that this was a mistake because such files Cannot be correctly parsed into PHP code by the PHP interpreter. If we directly request such a file on the server, we will get the source code of the file. This is because when PHP is used as an Apache module, the PHP interpreter determines whether to parse it into PHP based on the file extension. of code. The extension is specified by the site administrator, usually ".php", ".php3" and ".php4". If important configuration data is contained in a PHP file without the appropriate extension, it is easy for a remote attacker to obtain this information. The simplest solution is to specify a PHP file extension for each file. This can well prevent the leakage of source code, but it also creates new problems. By requesting this file, the attacker may make the Code running within the context operates independently, which can lead to all of the attacks discussed previously. Here is an obvious example: In main.php: In libdir/loadlanguage.php: It is quite safe when "libdir/loadlanguage.php" is called by "main.php", but because "libdir/loadlanguage" has " .php" extension, so a remote attacker can request this file directly and specify the values of "$langDir" and "$userLang" arbitrarily. [Session file] PHP 4 or newer versions provide support for sessions. Its main function is to save state information between pages in the PHP program. For example, when a user logs in to the website, the fact that he logged in and who logged in to the website are saved in the session, and when he browses around the website, all PHP code can obtain this state information. In fact, when a session is started (actually set in the configuration file to automatically start on the first request), a random "session id" is generated, which if the remote browser always submits when sending the request If this "session id" is used, the session will always be maintained. This is easily accomplished via cookies, or by submitting a form variable (containing the "session id") on each page. PHP programs can use session to register a special variable. Its value will be stored in the session file after each PHP script ends, and will also be loaded into the variable before each PHP script starts. Here is a simple example: New versions of PHP will automatically set the value of "$session_auth" to "shaun". If they are modified, future scripts will automatically accept the modified values, which is very important for the stateless Web. It is indeed a very good tool, but we should also be careful. An obvious problem is to ensure that the variable actually comes from the session. For example, given the above code, if the subsequent script looks like this: The above code assumes that if "$session_auth" is set, it is from the session, not from the session. The bit is set by user input. If an attacker sets the bit through form input, he can gain access to the site. Note that the attacker must register the variable in the session before using this attack method. Once the variable is put into the session, it will overwrite any form input. Session data is generally saved in a file (the location is configurable, usually "/tmp"). The file name is generally in the form of "sess_". This file contains variable names, variable types, variable values and some other data. . In a multi-host system, because the file is saved as the user running the web server (usually nobody), a malicious site owner can create a session file to gain access to other sites, and even inspect the session file. sensitive information in. The Session mechanism also provides another convenient place for attackers to save their own input in files on the remote system. For the above example, the attacker needs to place a file containing PHP code on the remote system. If the file cannot be used If the upload is successful, he usually uses the session to assign a value to a variable according to his own wishes, and then guesses the location of the session file, and he knows that the file name is "php", so he only needs to guess the directory, and the directory is usually "/ tmp".In addition, the attacker can arbitrarily specify a "session id" (such as "hello"), and then use this "session id" to create a session file (such as "/tmp/sess_hello"), but the "session id" can only be letters and numbers. combination. [Data types] PHP has loose data types, and the types of variables depend on the context in which they are located. For example: "$hello" starts as a string variable with a value of "", but when evaluated, it becomes an integer variable "0", which may sometimes lead to some unexpected results. If the value of "$hello" is different between "000" and "0", the result returned by empty() will not be true. Arrays in PHP are associative arrays, that is, the indexes of the array are string types. This means that "$hello["000"]" and "$hello[0]" are also different. The above issues should be carefully considered when developing a program. For example, we should not test whether a variable is "0" in one place and use empty() to verify it in another place. [Error-prone functions] When we analyze vulnerabilities in PHP programs, if we can get the source code, then a list of error-prone functions is what we need very much. If we can remotely change the parameters of these functions, then we are likely to find vulnerabilities. The following is a more detailed list of error-prone functions: require(): Read the contents of the specified file and interpret it as PHP code include(): Same as above eval(): Execute preg_replace() on the given string as PHP code : When used with the "/e" switch, the replacement string will be interpreted as PHP code exec(): Execute the specified command, return the last line of the execution result passthru(): Execute the specified command, return all results To the client browser: Execute the specified command and return all results to an array system(): Same as passthru(), but does not process binary data popen(): Execute the specified command and connect the input or output to the PHP file descriptor fopen(): Open the file and correspond to a PHP file descriptor readfile(): Read the content of the file, and then output it to the client browser file(): Read the entire file content into an array Translator's note: In fact, this list is not complete. For example, commands such as "mail()" may also execute commands, so you need to add it by yourself. [How to enhance the security of PHP] All the attacks I introduced above can be implemented well for the default installation of PHP 4, but I have repeated it many times. The configuration of PHP is very flexible. By configuring some PHP options, we It is entirely possible to resist some of these attacks. Below I have classified some configurations according to the difficulty of implementation: * Low difficulty ** Medium and low difficulty *** Medium and high difficulty **** High difficulty The above classification is just a personal opinion, but I can guarantee that if you use PHP If all the options are provided, then your PHP will be very safe, even with third-party code, because many of its features are no longer available. **** Set "register_globals" to "off" This option will disable PHP from creating global variables for user input, that is, if the user submits the form variable "hello", PHP will not create "$hello", but only create "HTTP_GET/POST_VARS[hello]". This is an extremely important option in PHP. Turning off this option will bring great inconvenience to programming. ***Set "safe_mode" to "on" and turn on this option, the following restrictions will be added: 1. Limit which commands can be executed 2. Limit which functions can be used 3. File access restrictions based on script ownership and target file ownership 4. Disable File Uploads This is a great option for ISPs and it can greatly improve PHP security. ** Setting "open_basedir" this option can prohibit file operations outside the specified directory, effectively eliminating attacks by include() on local files or remote files, but you still need to pay attention to attacks on file uploads and session files. ** Set "display_errors" to "off" and set "log_errors" to "on". This option prohibits error messages from being displayed on the web page, but is recorded in the log file. This can effectively prevent attackers from attacking functions in the target script. detection. * Set "allow_url_fopen" to "off". This option can disable the remote file function. It is highly recommended! Well, the article ends here. If you want to know some other related information, please refer to the original article http://www.securereality.com.au/studyinscarlet.txt.

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