PHP Security-Code Injection

Code Injection

A particularly dangerous situation is when you try to use tainted data as the leading part of a dynamic include:

In this scenario an attacker can manipulate not only the file name, but also the contained resources. Since PHP can not only include files by default, it can also include the following resources (controlled by allow_url_fopen in the configuration file):

The include statement will include the web page source code of http://www.php.cn/ as a local file at this time. While the above example is harmless, imagine what would happen if the source code returned by GOOGLE contained PHP code. This way the PHP code contained within it will be parsed and executed. This is an opportunity for attackers to release malicious code to defeat your security system.

Imagine that the path value points to the following resource controlled by the attacker:

http://www.php.cn/ ... e.org%2Fevil.inc%3F

In the above example, the value of path is URL encoded, and the original value is as follows:

http://www.php.cn/

This causes the include statement to include and execute the script selected by the attacker (evil.inc), and the original file name/header.inc will be considered a request string:

This avoids the need for the attacker to guess the remaining directory and filename (/header.onc) and create the same path and filename on evil.example.org. On the contrary, when the specific file name of the attacked website is blocked, he only needs to ensure that evil.inc outputs the legal code he wants to execute.

This situation is just as dangerous as allowing an attacker to modify the PHP code directly on your website. Fortunately, this can be prevented by filtering the data before the include and require statements:

The above is the content of PHP security-code injection. For more related content, please pay attention to the PHP Chinese website (www.php.cn )!