Shulou(Shulou.com)06/03 Report--

This article mainly explains "how to prevent loopholes in PHP programs". The content in the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "how to prevent loopholes in PHP programs".

Abuse of include

1. The cause of the vulnerability:

Include is the most commonly used function in writing PHP sites and supports relative paths. There are many PHP scripts that directly take an input variable as a parameter of Include, causing vulnerabilities such as arbitrary reference scripts, absolute path disclosure, and so on. Look at the following code:

...

$includepage=$_GET ["includepage"]

Include ($includepage)

...

Obviously, we just need to submit different Includepage variables to get the page we want. If you submit a page that does not exist, you can cause an error in the PHP script and reveal the actual absolute path (the solution to this problem is explained in the following article).

two。 Vulnerability resolution:

The solution to this vulnerability is very simple, which is to determine whether the page exists before Include. Or, more strictly, use arrays to specify Include files. Look at the following code:

The copy code is as follows:

$pagelist=array ("test1.php", "test2.php", "test3.php"); / / the file for which include can be performed

If (isset ($_ GET ["includepage"])) / / determine whether there is a $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!) ;}

}

In this way, the problem can be solved well.

Tip: there are other functions with this problem: require (), require_once (), include_once (), readfile (), etc., which should be paid attention to when writing.

Input variables are not filtered

1. The cause of the vulnerability:

This vulnerability appeared in ASP as early as possible, and there were countless injection vulnerabilities at that time. But because PHP had little influence at that time, not many people could pay attention to this. For PHP, this vulnerability has a greater impact than ASP because more PHP scripts use text-based databases. Of course, there is also the problem of injecting SQL statements. To give a more classic example, the first is the database:

The copy code is as follows:

$id=$_GET ["id"]

$query= "SELECT * FROM my_table where id='". $id. "'"; / / A classic SQL injection vulnerability

$result=mysql_query ($query)

It is clear here that we can use injection to get the rest of the database. It will not be described in detail here, the same as ASP injection, you can take a look at the previous black defense. Then let's look at the problem of text databases:

The copy code is as follows:

$text1=$_POST ["text1"]

$text2=$_POST ["text2"]

$text3=$_POST ["text3"]

$fd=fopen ("test.php", "a")

Fwrite ($fd, "\ r\ ntext1 assigned to text2) to text3")

Fclose ($fd)

The loophole in the text can be said to be more serious. If we insert a small piece of PHP code into our submitted variable, we can change the text database test.php into a PHP backdoor. Even insert the upload code so that we can upload a complete PHP backdoor. Then upgrade the permissions, and the server is yours.

two。 Vulnerability resolution:

The solution to this vulnerability is to strictly filter all submitted variables. Replace some sensitive characters. We can replace the contents of HTML with the htmlspecialchars () function provided by PHP. Here is an example:

The copy code is as follows:

/ / construct filter function

Function flt_tags ($text)

{

$badwords=array ("fuck", "fuck"); / / Vocabulary filter list

$text=rtrim ($text)

Foreach ($badwords as $badword) / / words are filtered 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 enter with

$text=str_replace ("\ r", "", $text)

$text=str_replace ("\ n", "", $text)

$text=str_replace ("& line;", "│", $text); / / the text database delimiter "& line;" is replaced with the full-width "│"

$text=preg_replace ("/\ s {2} /", ", $text); / / replace China Network Management Alliance with spaces

$text=preg_replace ("/\ t /", "", $text); / / or space replacement

If (get_magic_quotes_gpc ()) {$text=stripslashes ($text);} / / if magic_quotes is enabled, replace\'

Return $text

}

$text1=$_POST ["text1"]

$text2=$_POST ["text2"]

$text3=$_POST ["text3"]

/ / filter all inputs

$text1=flt_tags ($text1)

$text2=flt_tags ($text2)

$text3=flt_tags ($text3)

$fd=fopen ("test.php", "a")

Fwrite ($fd, "\ r\ ntext1 assigned to text2) to text3")

Fclose ($fd)

After some replacement and filtering, you can safely write the data to the text or database.

The administrator's judgment is incomplete.

1. The cause of the vulnerability:

When we write scripts in PHP, it usually involves the privileges of the administrator. On the other hand, some scripts only make a "yes" judgment on administrator permissions, but often ignore the "no" judgment. When register_globals is turned on in the PHP configuration file (after 4.2.0, it is turned off by default, but many people open it for convenience, this is extremely dangerous behavior), there will be submission variables impersonating administrators. Let's take a look at the example code:

The copy code is as follows:

$cookiesign= "admincookiesign"; / / determine whether it is a cookie variable of Admin

$adminsign=$_COOKIE ["sign"]; / / get the user's cookie variable

If ($adminsign==$cookiesign)

{

$admin=true

}

If ($admin) {echo "is now in the administrator state." ;}

It looks like it's safe, hehe. Now let's assume that register_globals is open in the PHP configuration file. We submitted such an address "test.php? admin=true". Did you see the result? Although we do not have the correct Cookie, because register_globals is open, the admin variable we submitted is automatically registered as true. And the lack of a "no" judgment in the script makes it easy for us to get administrator privileges through admin=true. This problem exists in most websites and forums.

two。 Vulnerability resolution:

To solve this problem, we only need to add a "no" judgment to the administrator in the script. We still assume that register_globals is open in the PHP configuration file. Take a look at the code:

The copy code is as follows:

$cookiesign= "admincookiesign"; / / determine whether it is a cookie variable of Admin

$adminsign=$_COOKIE ["sign"]; / / get the user's cookie variable

If ($adminsign==$cookiesign)

{

$admin=true

}

Else

{

$admin=false

}

If ($admin) {echo "is now in the administrator state." ;}

In this way, even if the attacker submits the variable of admin=true without the correct Cookie, the script will set $admin to False in its later judgment. This solves part of the problem. But because $admin is a variable, if there are vulnerabilities in other script references that cause $admin to be reassigned, it will cause a new crisis. Therefore, we should use constants to store the determination of administrator permissions. Use the Define () statement to define an admin constant to record administrator permissions. After that, there will be an error if re-assigned to achieve the purpose of protection. Look at the following code:

The copy code is as follows:

$cookiesign= "admincookiesign"; / / determine whether it is a cookie variable of Admin

$adminsign=$_COOKIE ["sign"]; / / get the user's cookie variable

If ($adminsign==$cookiesign)

{

Define (admin,true)

}

Else

{

Define (admin,false)

}

If (admin) {echo "is now in the administrator state." ;}

It is worth noting that we use the Define statement, so instead of the habitual variable symbol $before calling the Admin constant, use Admin and! admin.

Text database exposure

1. The cause of the vulnerability:

As mentioned earlier, text databases do not require any external support because of their flexibility. In addition, PHP has a strong ability to deal with files, so text database is widely used in PHP scripts. There are even several good forum programs that use text databases. However, there are gains and losses, and the security of text databases is lower than that of other databases.

two。 Vulnerability resolution:

Text database as an ordinary file, it can be downloaded, just like MDB. So we need to protect the text database by protecting MDB. Change the suffix of the text database to .PHP. And add in the first row of the database. The text database will then act as a PHP file and exit execution on the first line. That is, an empty page is returned to protect the text database.

Error path disclosure

1. The cause of the vulnerability:

When PHP encounters an error, it gives the location, number of lines, and cause of the error script, for example:

Notice: Use of undefined constant test-assumed 'test' in D:\ interpub\ bigfly\ test.php on line 3

A lot of people say it's no big deal. But the consequence of revealing the actual path is unthinkable, and this information is very important for some intruders, but in fact, there are a lot of servers that have this problem.

Some network managers simply set the display_errors in the PHP configuration file to Off to solve the problem, but I think this method is too negative. Sometimes we do need PHP to return error information for debugging. And when something goes wrong, you may need to give the user an explanation, or even navigate to another page.

two。 Vulnerability resolution:

PHP has provided a custom error handler function set_error_handler () since 4. 1. 0, but few scripting writers know about it. In many PHP forums, I have seen only a few of them deal with this situation. The usage of set_error_handler is as follows:

String set_error_handler (callback error_handler [, int error_types])

Now let's filter out the actual path with custom error handling.

The copy code is as follows:

/ / admin is the identity of the administrator, and true is the administrator.

/ / the custom error handler must have these four input variables $errno,$errstr,$errfile,$errline, otherwise it is invalid.

Function my_error_handler ($errno,$errstr,$errfile,$errline)

{

/ / filter the actual path if it is not an administrator

If (! admin)

{

$errfile=str_replace (getcwd (), "", $errfile)

$errstr=str_replace (getcwd (), "", $errstr)

}

Switch ($errno)

{

Case E_ERROR:

Echo "ERROR: [ID $errno] $errstr (Line: $errline of $errfile)

\ n "

The echo "program has stopped running, please contact your administrator."

/ / exit the script if you encounter an Error-level error

Exit

Break

Case E_WARNING:

Echo "WARNING: [ID $errno] $errstr (Line: $errline of $errfile)

\ n "

Break

Default:

/ / errors at Notice level are not displayed

Break

}

}

/ / set error handling to my_error_handler function

Set_error_handler ("my_error_handler")

...

In this way, the contradiction between safety and convenient debugging can be well solved. And you can also make some efforts to make the error tips more beautiful to match the style of the site. However, two points to note are:

(1) E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING will not be handled by this handle, that is, they will be displayed in the most primitive way. However, these errors are due to compilation or PHP kernel errors and do not normally occur.

(2) after using set_error_handler (), error_reporting () will fail. That is, all errors (except those above) are handed over to the custom function.

For other information about set_error_handler (), you can refer to the official manual of PHP.

POST vulnerability

1. The cause of the vulnerability:

As mentioned earlier, relying on register_globals to register variables is a bad habit. In some guestbook and forum programs, it is more important to strictly check the way you get the page and the time interval between submissions. To prevent irrigation posting and external submission. Let's take a look at the code of one of the following messages:

The copy code is as follows:

...

$text1=flt_tags ($text1)

$text2=flt_tags ($text2)

$text3=flt_tags ($text3)

$fd=fopen ("data.php", "a")

Fwrite ($fd, "\ r\ ntext1 assigned to text2) to text3")

Fclose ($fd)

Obviously, if we submit the URL "post.php?text1=test&text2=test&text3= test". The data is normally written to the file. This program does not detect the source of the variable and how the browser gets the page. If we repeatedly submit to this page, it will be used as a flood. Now there are also some software that take advantage of this loophole to advertise on forums or guestbooks, which is a shameful behavior (my friend's message has been filled with more than 10 pages in a week, helpless).

two。 Vulnerability resolution:

Before processing and saving the data, first judge how the browser gets the page. Use the $_ SERVER ["REQUEST_METHOD"] variable to get how the browser gets the page. Check if it is "POST". Use session in the script to record whether the user submitted the data through the normal way (that is, filling in the page of the submitted content). Or use $_ SERVER ["HTTP_REFERER"] to detect, but this is not recommended. Because some browsers do not set REFERER, some firewalls also block REFERER. In addition, we also check the submission to see if there are any duplicates in the database. Take the guestbook as an example, use Session to determine:

On the page that filled in the browsing content, we added at the front:

$_ SESSION ["allowgbookpost"] = time (); / / time at the time of registration

On the page where we accept the message data and save it, we also use Session to do the following before processing the data:

The copy code is as follows:

If (strtoupper ($_ SERVER ["REQUEST_METHOD"])! = "POST") {die ("error: do not submit externally.") ;} / / check whether the page acquisition method is POST

If (! isset ($_ SESSION ["allowgbookpost"]) or (time ()-$_ SESSION ["allowgbookpost"] < 10) {die ("error: do not submit externally.") ;} / / check the time when the message is filled in

If (isset ($_ SESSION ["gbookposttime"]) and (time ()-$_ SESSION ["gbookposttime"] < 120) {die ("error: the interval between submitting messages should not be less than 2 minutes.") ;} / / check the message interval

Unset ($_ SESSION ["allowgbookpost"]); / / Log out the allowgbookpost variable to prevent multiple submissions from entering the fill-in page at a time

$_ SESSION ["gbookposttime"] = time (); / / register the time when messages are sent to prevent flooding or malicious attacks

...

Data processing and preservation

Thank you for your reading, the above is the content of "how to prevent the loopholes produced by the PHP program". After the study of this article, I believe you have a deeper understanding of how to prevent the loopholes generated by the PHP program, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.