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, "\r\n$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 functions
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.) "); }
}
$text =htmlspecialchars ($text); HTML replacement
These two lines replace the carriage return with the

$text =str_replace ("\ r", "
", $text);
$text =str_replace ("\ n", "", $text);
$text =str_replace ("&line;", "│", $text); Text Database Separator "&line;" Replace with full corner "│"
$text =preg_replace ("/\s{2}/", "", $text); Space substitution
$text =preg_replace ("/\t/", "", $text); or a space replacement
if (GET_MAGIC_QUOTES_GPC ()) {$text =stripslashes ($text);///If Magic_quotes is turned on, replace with \
return $text;
}

$text 1=$_post["Text1"];
$text 2=$_post["Text2"];
$text 3=$_post["Text3"];

Filter All input
$text 1=flt_tags ($text 1);
$text 2=flt_tags ($text 2);
$text 3=flt_tags ($text 3);

$FD =fopen ("test.php", "a");
Fwrite ($FD, "\r\n$text1&line; $text 2&line; $text 3");
Fclose ($FD);
After a few substitutions and filtering, you can safely write data to a text or database.

Administrators are not completely judged
1. The reason of the loophole:
We use PHP to write scripts, which usually involve administrator permissions issues. Some scripts only make "yes" judgments on administrator rights, but often ignore "no" judgments. In the case of register_globals open in the PHP configuration file (4.2.0 after the version is closed by default, but many people open it for convenience, which is extremely dangerous behavior), there will be a submission variable posing as an administrator. Let's take a look at the example code:
$cookiesign = "Admincookiesign"; To determine whether the admin cookie variable
$adminsign =$_cookie["sign"]; Get the user's cookie variable

if ($adminsign = = $cookiesign)
{
$admin =true;
}

if ($admin) {echo is now an admin state. "; }
Looks like a safe look, hehe. Now let's assume that the PHP configuration file is register_globals open. We submit such an address "test.php?admin=true", the result is to see it? We do not have the correct cookie, but because Register_globals is turned on, the admin variable we submitted is automatically registered as true. And the script lacks "no" judgment, which makes us successfully get the administrator's permission through Admin=true. This problem exists in most websites and forums.
2. Vulnerability Resolution:
To solve this problem, we just need to add a "no" to the admin in the script. We still assume that Register_globals is open in the PHP configuration file. Look at the code:
$cookiesign = "Admincookiesign"; To determine whether the admin cookie variable
$adminsign =$_cookie["sign"]; Get the user's cookie variable

if ($adminsign = = $cookiesign)
{
$admin =true;
}
Else
{
$admin =false;
}
if ($admin) {echo is now an admin state. "; }
In this way, even if an attacker submits a admin=true variable without the correct cookie, the script will set the $admin to false in future judgments. This solves some of the problems. However, since $admin is a variable, a vulnerability in subsequent script references may cause a new crisis if the $admin is assigned a value. Therefore, we should use constants to hold the decision of administrator permissions. Use the Define () statement to define an admin constant to record administrator permissions, which can be followed by an error if the assignment is assigned again, for protection purposes. Look at the following code:
$cookiesign = "Admincookiesign"; To determine whether the admin cookie variable
$adminsign =$_cookie["sign"]; Get the user's cookie variable

if ($adminsign = = $cookiesign)
{
Define (admin,true);
}
Else
{
Define (ADMIN,FALSE);
}
if (Admin) {Echo is now an admin state. "; }
It is worth noting that we used the Define statement, so before calling the admin constant, we should not use the variable symbol $, instead of admin and!admin.

[1] [2] Next page