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

How to attack common vulnerabilities in PHP programs (Part 2)
Translation: analysist (analyst)
Source: http://www.china4lert.org

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

Original author: Shaun Clowes
Translation: analysist

[Library file]
As we discussed earlier, include() and require() are mainly to support the code library, because we generally put some frequently used functions into a separate In the file, this independent file 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, but they soon discovered that this was Error because such a file 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 creates new problems. By requesting this file, An attacker could cause code that should be running in the context to run independently, which could lead to all of the attacks discussed previously.

The following is an obvious example:

In main.php:
$libDir = "/libdir";
$langDir = " $libdir/languages";

...

include("$libdir/loadlanguage.php":
?>

In libdir/loadlanguage.php :
...

include("$langDir/$userLang");
?>

When "libdir/loadlanguage.php " is quite safe when called by "main.php", but because "libdir/loadlanguage" has a ".php" extension, a remote attacker can directly request this file and arbitrarily specify "$langDir" and " $userLang" value.
[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 is saved in the session, and all PHP code can obtain this status information when he browses around the website.

In fact, when a session is started (actually set in the config file to automatically start on the first request), a random "session id" is generated, if the remote browser always sends the request If you submit this "session id", the session will be maintained. This is easily achieved through cookies, or by submitting a form variable (containing "session id") on each page. PHP programs can register a special session. 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:

session_destroy(); // Kill any data currently in the session
$session_auth = "shaun";
session_register("session_auth"); // Register $session_auth as a session variable
?>

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 does come from the session. For example, given the above code, if the subsequent script is as follows:

if ( !empty($session_auth))
// Grant access to site here
?>

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 type, variable value 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 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. file, if it cannot be done by file upload, he usually uses 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 You need to guess the directory, which is usually "/tmp".

In addition, the attacker can arbitrarily specify the "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 a combination of letters and numbers.

[Data Type]
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 to say, the index of the array is of string type. 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 the given string as PHP code
preg_replace(): When used with the "/e" switch, the replacement string will be interpreted as PHP code


exec(): Execute the specified command and return the last line of the execution result
passthru(): Execute the specified command and 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 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 and the configuration of PHP is very flexible. By configuring some PHP options, we may be able to resist some of these attacks. Below I have classified some configurations according to the difficulty of implementation:

*Low difficulty
**Medium-low difficulty
***Medium-high difficulty
****High difficulty

The above classification is just a personal opinion, but I can guarantee that if you use all the options provided by PHP, then your PHP will be very safe, even if it is third-party code, because there are many functions It is 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 it "$hello", while only "HTTP_GET/POST_VARS['hello']" will be created. This is an extremely important option in PHP. Turning off this option will bring great inconvenience to programming.

*** Set "safe_mode" to "on"
Turn this option on, 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 upload function
This is a great option for ISPs, and it can also greatly improve PHP security.

** Set "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 file uploads and session file attacks.

** Set "display_errors" to "off" and set "log_errors" to "on"
This option disables error messages from being displayed on the web page and instead records them in the log file, which can be effective Resist the attacker's detection of functions in the target script.

* Set "allow_url_fopen" to "off"
This option can disable the remote file function, highly recommended!

Okay, 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.

http://www.bkjia.com/PHPjc/315335.htmlwww.bkjia.comtruehttp: //www.bkjia.com/PHPjc/315335.htmlTechArticleHow to attack common vulnerabilities in PHP programs (Part 2) Translation: analysist (analyst) Source: http: //www.china4lert.org How to attack common vulnerabilities in PHP programs (Part 2)...