The war in the PHP hole

Misuse of include
1. The reason of the loophole:
Include is the most commonly used function in writing PHP Web sites, and supports relative paths. There are many PHP scripts that directly take an input variable as an include parameter, resulting in arbitrary reference scripts, absolute path leaks and other vulnerabilities. Look at the following code:
...
$includepage =$_get["Includepage"];
Include ($includepage);
...
Obviously, we just need to submit a different includepage variable to get the desired page. If you submit a nonexistent page, you can make the PHP script error and reveal the actual absolute path (the solution to this problem is described in the following article).
2. Vulnerability Resolution:
The solution to this vulnerability is simple, that is, to determine whether the page exists before the include. Or, more strictly, use arrays to make provisions for files that can be include. Look at the following code:
$pagelist =array ("test1.php", "test2.php", "test3.php"); This provides the documentation that can be used to include
if (Isset ($_get["Includepage"))//Judge if there is $includepage
{
$includepage =$_get["Includepage"];
foreach ($pagelist as $prepage)
{
if ($includepage = = $prepage)//Check whether the file is in the Allow list
{
Include ($prepage);
$checkfind =true;
Break
}
}
if ($checkfind ==true) {unset ($checkfind);}
Else{die ("Invalid reference page!") "); }
}
This will be a good solution to the problem.
Tip: The function that has this problem also has: require (), require_once (), include_once (), ReadFile (), and so on, when writing also should notice.
The input variable is not filtered
1. The reason of the loophole:
This vulnerability was early in the ASP, and there were countless injection holes. But since PHP was less influential at the time, not too many people were able to pay attention. For PHP, this vulnerability has a greater impact than the ASP, because there are more PHP scripts used in the text database. Of course, there is an injection problem with SQL statements. For a more classic example, the first is the database:
$id =$_get["id"];
$query = "SELECT * from my_table where id= '". $id. ""; A classic SQL injection vulnerability
$result =mysql_query ($query);
It is clear that we can use injection to get the rest of the database. Here is no longer detailed description, and ASP injection, we can look at the previous black defense. And then we look at the problem with the text database:
$text 1=$_post["Text1"];
$text 2=$_post["Text2"];
$text 3=$_post["Text3"];
$FD =fopen ("test.php", "a");
Fwrite ($FD, "rn$text1&line; $text 2&line; $text 3");
Fclose ($FD);
The loopholes in the text can be said to be more serious. If we commit a variable to insert a small PHP code, we can another text database test.php into a PHP back door. Even insert the upload code so that we can upload a perfect php back door. Then elevate the permissions, and the server is yours.
2. Vulnerability Resolution:
The solution to this vulnerability is simply to filter all the submitted variables in a strict manner. Replace some of the sensitive characters. We can use the Htmlspecialchars () function provided by PHP to replace the content of HTML. Here is an example:
Constructing filter Function Www.111cn.net
function Flt_tags ($text)
{
$badwords =array ("Your Mother", "fuck"); Glossary filter List
$text =rtrim ($text);
foreach ($badwords as $badword)//The filtering of words here
{
if (Stristr ($text, $badword) ==true) {die (Error: The content you submitted contains sensitive words, please do not submit sensitive content