How to attack Common Vulnerabilities in PHP programs (below ). [Library files] as we discussed earlier, include () and require () are mainly used to support code libraries, because we usually put some frequently used functions into an independent file [library file], as we have discussed earlier, include () and require () are mainly used to support the code library, because we usually put some frequently used functions into an independent file, and this independent file is the code base. when you need to use the functions, we only need to include this code library in the current file. Initially, when people develop and publish PHP programs, in order to distinguish between the code library and the main program code, they generally set a ". inc, but they soon discovered that this is an error because such files cannot be correctly parsed as 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, because when PHP is used as an Apache module, the PHP interpreter determines whether to parse the file into PHP code based on the file extension. The extension is specified by the site administrator, generally ". php", ". php3", and ". php4 ". If important configuration data is contained in a php file without a proper extension, remote attackers can easily obtain this information. The simplest solution is to specify a php file extension for each file, which can prevent leakage of source code, but a new problem occurs. by requesting this file, attackers may make the code that should have been run in the context environment run independently, which may lead to all the attacks discussed above. The following is an obvious example: In main. php: In libdir/loadlanguage. php: When "libdir/loadlanguage. php "is" main. php is safe to call, but because "libdir/loadlanguage" has ". therefore, remote attackers can directly request this file and specify the values of "$ langDir" and "$ userLang. [Session file] PHP 4 or the updated version provides support for sessions. its main function is to save the status information between pages in the PHP program. For example, when a user logs on to the website, the fact that he logs on to the website and who logs on to the website are stored in the session. when he browses around the website, all PHP code can obtain the status information. In fact, when a session is started (in fact, it is set to automatically start at the first request in the configuration file), a random "session id" is generated ", if the remote browser always submits this "session id" when sending requests, the session will remain. This is easily achieved through cookies, or by submitting a form variable (including the "session id") on each page. A php program can use session to register a special variable. its value will exist in the session file after each PHP script ends, and will be loaded into the variable before each PHP script starts. The following is a simple example: the new PHP version automatically sets the value of "$ session_auth" to "shaun". if they are modified, later scripts will automatically accept the modified value, which is indeed a good tool for stateless Web, but we should be careful. An obvious problem is to ensure that the variables do come from the session. for example, if the above code is given, if the subsequent script is as follows: the above code assumes that if "$ session_auth" is set from the session rather than from the user input, if the attacker uses form input to set the bit, you can obtain access to the site. Note that the attacker must use this attack method before the session registers the variable. Once the variable is put into the session, it will overwrite any form input. Session data is generally stored in a file (the location is configurable, generally "/tmp"), and the file name is generally in a format similar to "sess _". This file contains the variable name, variable type, variable value, and some other data. In a multi-host system, files are saved as users running Web servers (generally nobody, therefore, malicious site owners can create a session file to obtain access to other sites, and even check the sensitive information in the session file. The Session mechanism also provides another convenient place for attackers to store their input in remote system files. for the above example, an attacker needs to place a file containing PHP code in a remote system. if the file cannot be uploaded, the attacker usually uses session to assign a value to a variable as needed, then guess 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 generally "/tmp ". In addition, attackers can specify the "session id" (such as "hello") at will, and then use this "session id" to create a session file (such as "/tmp/sess_hello "), however, the "session id" can only be a combination of letters and numbers. [Data types] PHP has loose data types, and variable types depend on their context environment. For example, "$ hello" is a string variable and its value is "". However, when the value is evaluated, it becomes the integer variable "0 ", this may sometimes lead to unexpected results. If the value of "$ hello" is "000" or "0" is different, the results returned by empty () will not be true. Arrays in PHP are associated arrays, that is, the index of arrays is string type. This means that "$ hello [" 000 "]" and "$ hello [0]" are different. When developing a program, we should carefully consider the above issues. for example, we should not test whether a variable is "0" in one place, and use empty () in another place () to verify. [Error-prone functions] if we can obtain the source code when analyzing vulnerabilities in PHP programs, we need a list of error-prone functions. If we can remotely change the parameters of these functions, we may find the vulnerabilities. The following is a detailed list of error-prone functions: require (): reads the content of the specified file and serves as the PHP code explanation include (): Same as eval (): run preg_replace () as PHP code: when used with the "/e" switch, the replacement string is 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, returns all results to an array system (): Same as passthru (), but does not process binary data popen (): execute the specified command to connect the input or output to the PHP file descriptor <文件泄露> Fopen (): open the file and correspond to a php file descriptor readfile (): read the file content, and then output it to the client browser file (): read the entire file into an array. note: In fact, this list is not very complete. for example, commands such as "mail ()" may also execute commands, so you need to add it yourself. [How to Enhance PHP Security] all the attacks I introduced above can be well implemented for the default installed PHP 4, but I have already repeated many times and the PHP configuration is very flexible, by configuring some PHP options, we are likely to resist some of these attacks. Next, I classified some configurations based on the implementation difficulty: * low difficulty ** Medium difficulty ** the above classification is just my opinion, however, I can ensure that if you use all the options provided by PHP, your PHP will be safe, even for third-party code, because many of these functions are no longer available. * *** Setting "register_globals" to "off" will disable PHP from creating global variables for user input. that is to say, if the user submits the form variable "hello ", PHP does not create "$ hello", but only creates "HTTP_GET/POST_VARS [hello]". This is an extremely important option in PHP. disabling this option will cause great inconvenience to programming. * ** If you set "safe_mode" to "on", the following restrictions will be added: 1. limit which command can be executed 2. restrict which function can be used. 3. file access restrictions based on script ownership and target file ownership 4. disabling file upload is a great option for ISP, and it can greatly improve PHP Security. ** Setting the "open_basedir" option can disable file operations outside the specified directory, effectively eliminating the attacks of local files or remote files by include, however, you still need to pay attention to the file upload and session file attacks. ** Set "display_errors" to "off" and "log_errors" to "on". This option prohibits you from displaying error information on a webpage, but recording it into a log file, this effectively prevents attackers from detecting functions in the target script. * Setting "allow_url_fopen" to "off" can disable the remote file function, which is highly recommended! Now, the article is complete. For more information, see http://www.securereality.com.au/studyinscarlet.txt.
As we discussed earlier, include () and require () are mainly used to support the code library, because we generally put some frequently used functions in an independent file...
