Web Application Security Vulnerability Analysis and Prevention (ASP)

In the previous articles, we analyzed and described common Web Security Vulnerability attacks and prevention methods, we also learned that Web security vulnerabilities have a huge impact on website security operations and protection against leaks of Enterprise sensitive information. Therefore, we can effectively prevent Web application vulnerabilities, preventing Leakage of sensitive information is critical to website operations. Web Application Security Vulnerability Scanning can help us discover possible security vulnerabilities to some extent. However, due to the complexity of the Web application environment, as a result, many vulnerabilities cannot be detected by detection tools. The source code analysis method can analyze the workflow and implementation methods of Web applications, discover potential security risks during the implementation of each function. Below we analyze Web Application Security Vulnerabilities developed by ASP through source code analysis, and Describe feasible and effective preventive methods based on actual vulnerabilities.

After learning about common Web Security Vulnerability attack methods, we know that attacks against Web applications are actually attacks against Web Application variables and functions, A Web application obtains the information entered by the user. After processing by the Web application, the corresponding returned results are fed back. The process of obtaining user input information is the process of obtaining variables, and the process of processing Web applications is the process of using functions in the program to operate on variables. Therefore, the process of searching for Web application vulnerabilities is to find dangerous variables and functions. During the search process, the function can be used to search for dangerous variables, if the function is not strict enough to process the variables, the vulnerability may exist. Similarly, we can use dangerous functions to find variables for analysis. If the function has problems in processing the variables, if the variables are always controllable, it can also lead to the formation of vulnerabilities. In order to analyze and describe the vulnerabilities, we searched for a set of Web applications written in ASP on the Internet, and described the vulnerabilities through examples.

Variable acquisition

Web applications written in ASP are mainly implemented through the Request object in obtaining variables. Common examples include Request. queryString, Request. form and Request. serverVariables, etc. So when we get ASP program variables, we mainly look for the location where the Request object appears. To facilitate search for the Request feature keywords, we can use some editor tools such as Editplus and Dreamweaver to Perform Batch search for ASP files in the Web application directory to determine the location where the variables are obtained, as shown in 1, Editplus is used to search all ASP files in the Web application source code directory and find the location where the Request keyword appears.

Figure 1

Vulnerability Analysis and Prevention

After determining the variable acquisition process, we need to find the variable processing process of the Web application based on the location of the variable. If the Web application is not strict with the variable processing process, this will lead to the formation of vulnerabilities. After analyzing this set of ASP programs, we found that although the program has a small amount of code, there are a variety of security vulnerabilities, these vulnerabilities mainly include SQL injection, XSS, unauthorized access, and Rich Text Editor vulnerabilities.

SQL Injection Vulnerability

During the analysis of this program, we found that multiple files have SQL injection vulnerabilities, such as custom. asp and news_category.asp. The code in custom. asp is shown in figure 2.

Figure 2

We found that, after the program obtains the variable id through the GET method, it directly brings the variable id into the SQL statement without any filtering and displays the result. This is a typical SQL injection vulnerability, check whether the vulnerability exists.

We access custom. asp? The page with id = 1, and submit the value of id as id = 1 and 1 = 1. Access the page with the result returned as a normal result in the browser, as shown in 3.

Figure 3

Then, we submit id = 1 and 1 = 2, and then submit it in the browser again. The error page is returned after access, as shown in figure 4.

Figure 4

From the returned results, we can determine that the file does have the SQL injection vulnerability. When we submit id = 1 and 1 = 1, the content of the executed SQL statement is select * from custom where id = 1 and 1 = 1, because the result of id = 1 exists in the database, the purpose of submitting 1 = 1 is to submit a result of the constant establishment to facilitate and logic operations to determine whether the program filters the submitted data. Of course, the submission 2 = 2, 3 = 3, even 100 = 100, their principles are the same, so the two are true results after the and logic operation processing results are true, the returned page is a normal page. When id = 1 and 1 = 2 is submitted, because 1 = 2 is not valid, the results returned after the and logic operation are false, resulting in query errors. The error page is returned, then it verifies that the injection vulnerability exists. Then, using the SQL injection vulnerability we learned earlier, we know that hackers can easily obtain the Administrator account and password through this SQL injection vulnerability, as shown in Figure 5, hackers can easily exploit the SQL injection vulnerability to guess the Administrator account and password.

Figure 5

You can also directly expose the Administrator account and password information through union Joint query to avoid time-consuming SQL injection vulnerability exploitation tools, as shown in figure 6.

Figure 6

The news_category.asp file also has a severe SQL injection vulnerability. The 23-25 lines of code in this file are shown in 7.

Figure 7

From the code, we found that the file's SQL injection vulnerability is formed in principle and custom. asp vulnerabilities are created in exactly the same way. After obtaining the variable id data through GET, the data is imported into the SQL statement for query without any filtering, resulting in the formation of the SQL injection vulnerability, hackers can also use the methods described above to obtain sensitive data, as shown in figure 8, the injection vulnerability in news_category.asp is used to obtain Administrator account and password information through union Joint query.

Figure 8

After obtaining the Administrator account information and password-encrypted Md5 information, hackers can crack the Md5 encrypted password and log on to the management background for subsequent operations.

Prevent SQL Injection Vulnerabilities

Through the analysis and utilization of the preceding two SQL injection vulnerabilities, we found that the SQL injection vulnerability has a serious impact on the security of the program. During the analysis of the program code, we found that the author of the program did not have any security awareness at all, and added the judgment content of the variable on some pages, the code is shown in Figure 9.

Figure 9

After obtaining the variable id, the author determines whether the GET method obtains the id to be null or whether it is a number. If it is null or not a number, the author will prompt illegal operation information and stop the operation. However, no judgment is added to the SQL Injection page described above. To prevent SQL injection vulnerabilities, we can use the following methods.

1. When obtaining a numeric variable, You need to determine whether the submitted content is a number. If the content is not a number, the operation is considered illegal.

2. when getting a balanced variable, You need to determine whether the submitted content contains special characters that may affect the execution of SQL statements, such as single quotes. If there are special characters, the operation is considered invalid.

3. You can add a general anti-injection program to Web applications to prevent SQL injection attacks. General SQL Injection prevention programs are usually introduced in database connection files, and common GET, POST, Cookie, and other submission methods are filtered during program execution, block possible SQL injection attacks.

XSS Cross-Site Scripting Vulnerability

When analyzing this set of ASP programs, we found that there is a message function in this program, and the message function does not strictly filter the data submitted by users, resulting in the formation of the storage XSS cross-site scripting vulnerability.

In guestbook_add.asp, the program obtains the data submitted by the user through the POST method, and inserts the data into the database without strict filtering, as shown in code 10.

Figure 10

From the code, we found that the program only checks whether the name is blank and the format of the email and mobile phone number, and does not filter other data content, the stored XSS cross-site scripting vulnerability is verified below. As shown in figure 11, data is submitted on the submit message page.

Figure 11

XSS cross-site scripting (XSS) attacks can be caused when messages are viewed at the front-end and back-end, as shown in Figure 13.

Figure 12

Figure 13

XSS cross-site scripting vulnerability prevention

We have introduced how to prevent XSS cross-site scripting (XSS) attacks in the previous article, mainly for HTML encoding of special characters submitted, for example, common single quotes, double quotes, & symbols, <symbol and> symbols are used to filter malicious characters without affecting normal data display. For details, refer to pipeline.

Unauthorized Access Vulnerability

During the analysis of this set of programs, we found that after the Administrator logs on, the program judges whether the session ("user_name") is empty to determine whether the user accessing the page is an administrator, in the Administrator's background directory, most programs have already added sessions. the asp file implements the above judgment. However, during the analysis, we found that there are still a few files not introduced into the session. asp files lead to the formation of unauthorized access vulnerabilities. Files with this problem mainly include admin_delete.asp, admin_modify.asp, banner_delete.asp, banner_modify.asp, CategoryManagement. asp, custom_delete.asp, example, flink. asp, guestbook. asp, and guestbook_view.asp. These files are not introduced into the session. asp files allow hackers to directly perform page operations without the Administrator account and password or without logging on to the background. Below we will describe the pages with three serious hazards.

1. delete any administrator account

In admin_delete.asp under the admin directory, the session is not introduced. asp files are only used to determine whether the submitted id is a number or whether it is null. Then, they are included in the SQL statement to delete the administrator user with the specified id, as shown in Code 14.

Figure 14

For the above Code, even if hackers do not know the Administrator account Id, they only need to construct a URL list for batch access to delete the Administrator account, as shown in Figure 15, by submitting id = 3, delete the account with the specified administrator id 3.

Figure 15

2. modify any administrator password

This is the same as admin_delete.asp because no session is introduced. in the asp file, admin_modify.asp under the admin directory directly modifies the Administrator account and password of the specified id if you do not have the permission to access the page, as a result, hackers can exploit this vulnerability to modify any administrator password, as shown in Figure 16.

Figure 16

When id = 1 is submitted, you can directly access the Administrator account whose id is 1 and directly modify the administrator password by submitting a form, then, use the modified password to log on to the management background. The password change page is shown in figure 17.

Figure 17

3. Insert malicious code into the website homepage

In the admin directory, CategoryManagement. the asp file is used to modify the category information displayed on the home page because the session is not introduced. asp file, which allows hackers to directly modify the homepage category information by accessing the file, as shown in Figure 18.

Figure 18

This operation directly involves the display of the homepage code and does not filter the written data. As a result, hackers can write any data to the homepage, including malicious code, as shown in figures 19 and 20, hackers introduce other website code to the homepage by writing the iframe framework. If the Code contains malicious trojan code, users accessing the website will be attacked by malicious code.

Figure 19

Figure 20

Prevent Unauthorized Access Vulnerabilities

To prevent unauthorized access vulnerabilities of the program, you only need to determine whether the user accessing the page has administrator permissions. In this program, the author introduces seeion. asp file to determine, so you only need to in other sessions not introduced. add code to the asp background management File <! -- # Include file = "seeion. asp" --> introduce seeion. asp to implement judgment and prevention.

Rich Text Editor Vulnerability

In the background of the program, to facilitate convenient and convenient operations on text characters, the programmer introduces the third-party rich text editor software FckEditor, And the introduced FckEditor version is a version with the Upload File Vulnerability, hackers can exploit this Rich Text Editor vulnerability to upload webpage trojan files to obtain the website's webshell. Because the Fckeditor program restricts the upload of script files such as ASP and ASA, it can only be obtained through Parsing Vulnerabilities of IIS6 and later versions. Access FCKeditor/editor/filemanager/connectors/asp/connector. asp? Command = CreateFolder & Type = Image & CurrentFolder =/shell. asp & NewFolderName = shell. asp creates a shell in the defined upload directory. asp folder, and then upload an ASP one-sentence Trojan with the modified suffix gif under the folder, as shown in Figure 21.

Figure 21

Then, we click the uploaded file and find that a single-sentence Trojan is successfully written, and the ASP webshell with many functions is successfully written using this one-sentence Trojan, as shown in Figure 22 and Figure 23.

Figure 22

Figure 23

Prevent Rich Text Editor Vulnerabilities

The vast majority of Rich Text Editor programs are developed by third parties. Due to the complexity of the editor code, it is difficult for Web application programmers to modify the vulnerability of the editor itself, therefore, the prevention of Rich Text Editor vulnerabilities mainly includes the following aspects:

1. Delete unnecessary files. Because Rich Text editors are mostly developed by third parties, the functions are complex. For Web applications using the editors, only a part of the files are required. Therefore, for files outside the scope of use, we recommend that you delete it to prevent hacker intrusion due to vulnerabilities, such as admin_login.asp, admin_default.asp, and other files in the eWebedito program. It is not necessary for Web programs, so you can delete it, prevent hackers from logging on to the webshell file to directly obtain the webshell.

2. When the Rich Text Editor has a security vulnerability patch or a new version that is more secure, the programmer should fix or replace the file with a new version with a higher security.

3. you can add the Web application permission verification code to the called Rich Text Editor to prevent hackers from directly accessing the Rich Text Editor of the Web application, although this method cannot fundamentally solve the editor vulnerability, it can prevent hackers from directly calling Rich Text Editor related files for operations to a certain extent.

4. strictly restrict the write and script execution permissions of website directories, especially for permission settings for upload directories. Disable the script execution permission, even if the hacker uploads files to the web directory through the Upload Vulnerability, webshell cannot run because it has no execution permission.

By analyzing the source code of Web applications, it is an important part of code auditing. Through white-box testing of Web applications, we can find many complex and harsh vulnerability information hidden in Web applications. Therefore, in the routine security testing process, the code analysis and audit content should be added on the basis of the original black box testing to mine more information about vulnerabilities that can be exploited by hackers, protect the security of applications and data and prevent leakage of sensitive information.