PHP Security-code injection

A particularly dangerous situation is when you try to use contaminated data as the leading part of dynamic inclusion:

Code injection

A particularly dangerous situation is when you try to use contaminated data as the leading part of dynamic inclusion:

In this case, attackers can manipulate not only file names, but also the resources they contain. By default, PHP can contain not only files, but also the following resources (controlled by allow_url_fopen in the configuration file ):

At this time, the include statement will include the # Web page source code as a local file. Although the above example is harmless, imagine what happens if the source code returned by GOOGLE contains PHP code. In this way, the included PHP code will be parsed and executed. This is a good opportunity for attackers to release malicious code to destroy your security system.

Imagine that the path value points to the resources controlled by the following attackers:

#... E.org % 2fedevil. inc % 3F

In the preceding example, the path value is URL encoded. the original value is as follows:

#

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

In this way, attackers avoid the need to guess the remaining directory and file name (/header. onc) and establish the same path and file name on evil.example.org. On the contrary, when the specific file name of the website under attack is blocked, he only needs to ensure that the code he wants to execute is valid in edevil. inc.

This situation is as dangerous as allowing attackers to directly modify PHP code on your website. Fortunately, you only need to filter data before the include and require statements to prevent this situation:

The above is PHP Security-code injection content. For more information, see PHP Chinese website (www.php1.cn )!