Detailed explanation of common vulnerabilities in PHP programs

[Library file]
As we discussed earlier, include() and require() are mainly to support the code base, because we usually put some frequently used functions into a separate file. This independent file is the code base. When we need to use function, 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:
$libDir = "/libdir";
$langDir = "$libdir/languages";

...

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

In libdir/loadlanguage.php:
...

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

"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 the values for "$langDir" and "$userLang".
[Session file]
PHP 4 or newer versions provide support for sessions, whose 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:

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 really good for the stateless Web. tools, but we should also be careful.

An obvious question is to ensure that the variable does come from the session. For example, given the above code, if the subsequent script looks like this:

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

The above code assumes that if "$session_auth" is set, it is set from the session, not from user input. If an attacker sets it 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 name, 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 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, The directory is generally "/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 type]
PHP has loose data types, and the types of variables depend on the context in which they are found. 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 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 contents of the file and 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, "mail()" and other commands may also execute commands, so you need to add it by yourself.
[How to enhance PHP security]
All the attacks I introduced above can be implemented well against the default installation of PHP 4, but I have repeated it many times, PHP configuration is very flexible, and 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
**Low to medium difficulty
***Medium to High Difficulty
****High difficulty

The above classification is just my personal opinion, but I can guarantee that if you use the provided by PHP

Detailed explanation of common vulnerabilities in PHP programs_PHP tutorial