The nature of script security_PHP+MYSQL page 2/3

2 Implicit input
The above are the most primitive data without program conversion. The variables used in many places of the program come from here, but it does not mean that no variables are passed in other places. There is a data transfer pattern below:
Data passed by users===============>Database==============>Program code processing========>Program code
This pattern means that the user's input may first enter the database, and then the program obtains this input from the database and then sends it to some dangerous functions for execution. Ordinary programmers will have a sense that the variables obtained from the database are safe, but the fact is not the case. As long as some sensitive characters are finally sent to the program code, no matter where they stay in it, it is dangerous. Similar to stored in a database, some programs put user input into files, such as cache files, and then obtain them from them when necessary. If you trust the variables from these places too much, this will still lead to problems.
3 Variable overwrite
There are still many times when the variables received by the program are likely to come from places where it shouldn't be, such as Dz's code:
$magic_quotes_gpc = get_magic_quotes_gpc();
@extract(daddslashes($_POST));
@extract(daddslashes($_GET));
if(!$magic_quotes_gpc) {
$_FILES = daddslashes($_FILES);
}
After this, do you still think $_FILES is the original $_FILES? If we create a _FILES form or simply add php?_FILES[]=ddddd in the url, then $_FILES has been completely overwritten, and then the $_FILES referenced in your code is not the original one. This problem has occurred in previous versions of Dz. This should be a problem of variable overwriting. Let's enlarge the initialized file and take a look:

This seems to be fine, but if certain conditions are met, there may still be problems. Assuming register_globals is on, the variables we enter the global are not just $_GET and $_POST! Including $_COOKIE, $_FILES and $_SERVER will generate variables in the global array. Through the above statement, we submit a php?_SERVER[PHP_SELF] to overwrite the _SERVER array, so the $_SERVER array in the entire program is unbelievable. I've also seen codes written like this:

It is also in the system initialization place, but the release of variables is
require_once ROOT_PATH.'inc/general_funcs.php';
require_once ROOT_PATH.'inc/dv_spacemain.php';
After these key variables are initialized, we can completely submit a ?$host= such thing covers the database address variable in the system's own database initialization file, and then
4 variable infections
This is easy to understand. When a variable is unsafe, the assignment and other operations related to it are unsafe, such as:
$id = $_GET[id];
..
$articleid = $id;
The actual process may not be so obvious, but the result is the same. As long as a variable brings sensitive characters into places that should not be taken, it will create a threat. Not just variables, but unsafe functions will make all codes using this function unsafe.