Analysis and Handling of Website Security Vulnerabilities

Analysis and Handling of Website Security Vulnerabilities


1. Analysis and Handling of vulnerabilities in Web website programming


Author: Lu Yu


Currently, there are many network security industries in China, from anti-virus software and software firewalls for personal computers provided by anti-virus software companies such as Kingsoft, rising star, and Jiangmin to hardware firewalls for servers, more and more mature technologies. It can be said that it is not easy to break through the hardware firewall. Because there is no absolutely safe PC, server, or network in the world. As Kevin micnick, the godfather of hackers, said: "Human factors are the weakness of security !"

That's right! No matter how powerful and rigorous your hardware protection measures are, how rigorous the algorithms and structures of software programs are, and how strict the filtering is when web programs are compiled, the vulnerability caused by human factors is the most terrible, because it will never be prevented.

For example, in an Internet forum, do you say that the technical staff level is poor? After so many years of experience, mobile Internet has been constantly discovering so many vulnerabilities, many of which are low-level errors. Do they really don't know how to take a long journey of wisdom?

A pure static Web page does not know the background, FTP account password, and other information, but it is still taken down. Why? Today, let me give you an incomplete induction and brief analysis.

The basic security problems of a website are as follows:

First, let's take a look at the vulnerabilities caused by program omissions in the software writing process.

I. vulnerabilities in website programs

1. Injection Vulnerability

2. Incorrect format verification for uploaded files

3. The parameter can be written to a file-construct a sentence

4. The mdb database uses ASPASA and other names as the database extension (add anti-download code)

5. The database path is displayed in the background.

6. database backup and modification extensions

7. File Management Part transfer parameter filtering and external submission

8. XSS vulnerability defrauding cookies to obtain background Permissions

9. Arbitrary File Download Vulnerability

10. Remote Inclusion Vulnerability

11. Use unencrypted cookies for user permission level and permission Verification

12. session Spoofing

Let's briefly analyze the formation and solutions of these vulnerabilities.

1) Injection Vulnerability

Injection Vulnerability Generation Principle:

We can manually construct a query program with Injection Vulnerabilities. Here asp is simple and clear.

<! -- # Include file = "conn. asp" -->

<%

Id = request ("id ")

If id <> "" then

Set rs = Server. CreateObject ("ADODB. RecordSet ")

SQL = "select * from news where id =" & id

Rs. Open SQL, conn, 1, 1

Response. write "title:" & rs ("title") & "<br>"

Response. write "content:" & rs ("content ")

Set rs = nothing

Rs. colse

Else

Response. write "parameter missing"

End if

%>

This Code directly receives the id value from the browser and submits it to the database for query without any filtering.

First, let's determine whether injection exists. The common method is

And 1 = 1 returns normal

And 1 = 2 if an error is returned or no content is returned, the injection vulnerability exists. I am often lazy and add a "'" directly behind the address bar. if an error is returned or no content is returned, injection is considered.

Construct the injection statement:

And exists (select count (*) from admin)

Add this code to the address.

Http: // localhost/index. asp/id = 1and exists (select count (*) from admin)

Then the parameters received in the program are changed to the following joint query statement.

Then we bring the database query section. Let's see how it works.

SQL = "select * from news where id =" & 1 and exists (select count (*) from admin)

The result is obvious. The original single-sentence query becomes a joint query, and the admin table content is queried. This statement is used to determine whether a field exists. If a field exists, the query is successful. If the field does not exist, an error message is returned, indicating that the table does not exist. The detailed injection method is not described here.

Another trick is that some sites do not filter the entire site, which leads to some hidden injection points. For example, if a file filters the submitted id parameter values and cannot be injected, but you will notice that there are many parameters in the address bar, and one of them is not filtered, the injection vulnerability can also be generated.

For example:

Http: // localhost/index. asp? Class = 1 & id = 1

Sometimes, in a program, only the id parameter is filtered and the class is not filtered, which leads to a hidden injection point. Change the address

Http: // localhost/index. asp? Class = 1 and then inject

If the program does not process the non-null condition of the id parameter at this time, we may inject it smoothly.

Another situation is that some programmers write custom anti-injection functions, but they did not call them during programming, which still leads to the injection vulnerability.


In addition, we need to pay special attention to filtering cookie injection, because many website programmers are used to relying on the universal anti-injection system, however, the general anti-injection system of the old version has a problem, that is, it does not filter cookies.

That is to say, when we find that a website uses a universal anti-injection service, it proves that the website program does not filter the injection, when this website uses an old version of the general anti-injection program, it is equivalent to telling us that there is no silver three hundred. The following is to construct a simple cookie injection statement to easily win the background account password.

So programmers should pay special attention to the verification or hiding of the background address of the program. The following comments are raised on the background of the programmer:
1. Use a management verification code similar to the ease of use in the background

2. manually enter the correct address in the background address path and switch to the correct management background

3. You can customize the name and path of the background folder.

4. For non-open-source programs, use unconventional names for database table names and Field Names

1) vulnerabilities caused by the upload function

1. Verify that the extension is not strict, resulting in the upload of arbitrary or special files

Suggestion:

(1) Allow conforming files for verification without verifying the non-matching format

That is to say, when your website only needs users to upload jpg bmp gif rar zip files, the verification module only allows these files to be uploaded, instead of filtering the formats of files that cannot be uploaded and prompting errors. This avoids the upload of illegal files to the maximum extent.

(2) Verify the file header ID of the uploaded file. For example, the mobile network program verifies the image ID, so as to avoid the construction of a Trojan like a sentence in the example.

(3) detect additional files

There is a technology called "file hiding technology", which is actually to use a command copy 1.gif/a + 1.asp/B 1.gif under windows command line.

Merge two files. This method can be used to merge Trojans into the mdb database and save the files as a specified Trojan file through backup, therefore, programmers should pay special attention to this point during programming. The program of the dynamic network forum can be used as a reference.

(4) the upload directory cannot be dynamically generated.

The front-end time was hacked by a series of large websites, such as mobile devices, due to an IIS6 resolution vulnerability. The php trojan after login gets an access path.

Http://www.xxx.com/user/1.php/1.jpg

When we access this jpg file, the IIS6 vulnerability provides us with convenience. This jpg will be run as a php program. The result is obvious. We can get a webshell.

Therefore, you are not allowed to dynamically generate user upload directories. We recommend that you do not set upload directories. Because windows has a serious Bug that is automatically generated when the directory does not exist.

(5) do not set the upload verification format in the background.

Many websites allow you to set file formats that allow or prohibit upload in the background. This function is completely unnecessary. Although it provides more comprehensive and powerful functions, it enhances interaction. However, the security problems are far more powerful than their usability. Therefore, it is recommended that programmers do not provide this unnecessary function when developing website programs.

3) program parameters allow file writing

When analyzing the "Blue-wood enterprise management system", we found that many programs allow the setting of parameters in the background to allow file writing. This problem allows us to construct special statements to transform a parameter storage file into a Trojan, when the submitted Form restricts the length of the text field, we can construct a one-sentence Trojan Horse. Without filtering, we can directly write a Trojan. Therefore, it is recommended that programmers develop a good habit of saving parameter data to the database instead of storing it in files to avoid similar situations.

The following uses the blue-wood enterprise management system as an example for Demonstration:

All parameters here are written to the setup. asp file.

Because it does not filter the written parameters, we can manually write the parameters, end the statement in advance, and get a backdoor. We have modified the website name here and changed it:

Test "%> <% execute request (" value ") %> <% a =" 1

The modified configuration file content is found to be changed