Program | Attack library file]
As we discussed earlier, include () and require () are primarily designed to support code libraries, because we typically put some of the functions that are often used in a separate file, which is the code base, and when you need to use the functions in it, We just need to include this code library in the current file.
Initially, when people developed and published PHP programs, in order to distinguish between code base and main program code, they typically set an ". Inc" extension for the code base file, but they quickly discovered that this was a mistake because such a file could not be correctly parsed into PHP code by the PHP interpreter. If we directly request this file on the server, we will get the source code of the file, because when PHP is used as an Apache module, the PHP interpreter is based on the file extension to determine whether to parse the PHP code. The extension is specified by the site administrator, typically ". php", ". PhP3" and ". PhP4". If important configuration data is contained in a PHP file that does not have a suitable extension, it is easy for a remote attacker to get this information.
The easiest way to do this is to specify a php file extension for each file. This is a good way to prevent leaks from the source code, but it creates a new problem that, by requesting this file, an attacker could run the code that was supposed to run in the context, which could lead to all the attacks discussed earlier.
Here is an obvious example:
In main.php:
<?php
$libDir = "/libdir";
$langDir = "$libdir/languages";
...
Include ("$libdir/loadlanguage.php":
?>
In libdir/loadlanguage.php:
<?php
...
Include ("$langDir/$userLang");
?>
It is quite secure when "libdir/loadlanguage.php" is called "main.php", but because "libdir/loadlanguage" has an extension of ". PHP", remote attackers can request this file directly, And you can specify the values of $langDir and $userLang arbitrarily.
[Session file]
PHP 4 or newer versions provide support for sessions, whose primary role is to save state information between pages and page in a PHP program. For example, when a user logs on to the site, he logs on the fact and who logs into the site are saved in the session, and when he is browsing around the site, all the PHP code can get these status information.
In fact, when a session is started (which is actually set in the configuration file to start automatically on the first request), a random "Sessions ID" is generated, and if the remote browser always submits the "session ID" when the request is sent, The session will always be maintained. This is easy to implement with cookies, or it can be done by submitting a form variable (containing the session ID) on each page. PHP program can register a special variable with session, its value will be in the session file after each PHP script is finished, and will be loaded into the variable before each PHP script starts. The following is a simple example:
<?php
Session_destroy (); Kill any data currently in the session
$session _auth = "Shaun";
Session_register ("Session_auth"); Register $session _auth as a session variable
?>
The new version of PHP will automatically set the "$session _auth" value to "Shaun", if they are modified, the future script will automatically accept the modified value, which for the stateless web is indeed a good tool, but we should also be careful.
One obvious problem is to make sure that the variables actually come from the session, for example, given the code above, if the following script is the case:
<?php
if (!empty ($session _auth))
Grant Access to Site
?>
The above code assumes that if the "$session _auth" is placed, it is from the session, not from the user input to set the bit, if the attacker through the form input to place, he can gain access to the site. Note the attacker must use this attack method before the session registers the variable, and any form input will be overwritten once the variable is placed in session.
Session data is generally saved in a file (the location is configurable, generally "/tmp"), and the filename is generally similar to "Sess_<session id>", which contains the variable name, variable type, variable value, and some other data. In a multihomed system, because a file is saved as a user who is running a Web server (typically nobody), a malicious site owner can gain access to other sites by creating a session file, and can even check for sensitive information in the session file.
The session mechanism also provides another convenient place for an attacker to save his or her input in a remote system file, and for the above example, an attacker would need to place a file containing PHP code on the remote system, if the file could not be uploaded. He usually uses the session to assign a value to a variable, then guesses the location of the session file, and he knows that the filename is "php<session id>", so just guess the directory, and the directory is generally "/tmp".
In addition, an attacker could optionally specify "session ID" (such as "Hello") and then use this "session ID" to create a session file (such as "/tmp/sess_hello"), but "session ID" can only be a combination of letters and numbers.
[Data type]
PHP has a relatively loose data type, and the type of the variable depends on the context in which they are located. For example, "$hello" begins with a string variable with a value of "", but when evaluated, it becomes the reshaping variable "0", which can sometimes lead to unexpected results. If the value of "$hello" is different for "000" or "0", the result returned by empty () will not be true.
The array in PHP is an associative array, that is, the index of the array is a string type. This means that "$hello [" 000 "]" and "$hello [0]" are also different.
When developing a program, you should consider the above question carefully, 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 an error-prone list of functions is very much needed. If we can remotely change the parameters of these functions, then we are likely to discover the vulnerabilities. Here's a list of more detailed, error-prone functions:
<php Code execution >
Require (): reads the contents of the specified file and interprets it as a PHP code
Include (): Ibid.
Eval (): Executes the given string as a PHP code
Preg_replace (): When used with the "/e" switch, the replacement string will be interpreted as PHP code
< command execution >
EXEC (): Executes the specified command, returning the last row of the execution result
PassThru (): Executes the specified command, returns all results to the client browser
': Executes the specified command, returns all results to an array
System (): Same as PassThru (), but does not process binary data
Popen (): Executes the specified command to connect input or output to the PHP file descriptor
< file leaks >
fopen (): Opens the file and corresponds to a PHP file descriptor
ReadFile (): Read the contents of the file, and then output to the client browser
File (): Read the entire contents of the file into an array
In fact, this list is not very full, such as "Mail ()" and other commands may also execute orders, so need to add their own.
[How to enhance PHP security]
All of the attacks I've described above are well implemented for the default installed PHP 4, but I've repeated it many times, PHP has a very flexible configuration, and by configuring some PHP options, we are likely to be able to resist some of these attacks. Below I classify some configurations according to the difficulty of implementation:
* Low Difficulty
* * Medium and low difficulty
Medium and high difficulty
High Difficulty
The above classification is personal, but I can assure you that if you use all the options provided by PHP, your PHP will be safe, even for Third-party code, because many of these features are not available.
Set "Register_globals" to "off"
This option prevents PHP from creating global variables for user input, that is, if the user submits the form variable "Hello", PHP will not create "$ hello" and will only create "http_get/post_vars[' Hello". This is one of the most important options in PHP, and turning off this option can cause a lot of inconvenience to programming.
Set "Safe_mode" to "on"
Opening this option increases the following restrictions:
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. Prohibit file upload features
This is a great option for ISPs, and it can also greatly improve PHP security.
* * Set "Open_basedir"
This option prevents file operations outside the specified directory, effectively eliminating local files or attacks by include (), but still requires attention to file uploads and session file attacks.
* * Set "display_errors" to "off" and set "Log_errors" to "on"
This option prevents the error message from being displayed in the Web page, but is logged to the log file, which effectively resists the attacker's detection of the function in the target script.
* Set "Allow_url_fopen" to "off"
This option can prohibit remote file function, highly recommended!
OK, this is the end of the article, if you want to know some other relevant information, please refer to the original http://www.securereality.com.au/studyinscarlet.txt.
< finished full >
