Cookie Injection Attack and Defense in the Web Attack and Defense Series

With the development of network security technology, SQL injection is increasingly known as a popular attack method. Many websites also protect against SQL injection. Many website administrators add anti-injection programs. At this time, when we use conventional means to detect the website's SQL injection vulnerability, it will be blocked by the anti-injection program. What should we do in this situation? Is there no way? The answer is no.

We know that the general anti-injection program is based on the "black list", and some dangerous characters are filtered out according to the feature string. In general, the blacklist is insecure and there is a risk of being bypassed. For example, some anti-injection programs only filter data submitted through GET and POST, but do not filter the data submitted through Cookie. What should we do? You will find the answer in this article.

Cookie injection Principle

The Cookie was first proposed by Netscape. The Cookie definition in Netscape official documents is as follows: the Cookie is under the HTTP protocol, A server or script can maintain information on the customer's workstation.

Cookies are widely used and are often seen on the Internet. It is usually used to identify a user and track sessions. The most typical application is to save the user's account and password to automatically log on to the website and the "Shopping Cart" in the e-commerce website ".

Cookie injection is an injection attack initiated by using cookies. In essence, Cookie injection is no different from traditional SQL injection. Both are aimed at database injection, but the performance is slightly different.

To better understand the causes of Cookie injection, you must understand the request object in ASP scripts. It is used to obtain the data submitted by the client. First, let's take a look at the description of the request object in the ASP development document, as shown in 1:

Figure 1

The usage of the Request object is generally as follows: request. [set name] (parameter name). For example, when obtaining data submitted from the form, you can write the following statement: request. form ("parameter name"), but the set name can also be omitted in ASP. You can directly obtain data using this method: request ("parameter name "), when using this method to obtain data, ASP requires that data be obtained in the order of QueryString, Form, Cookies, and ServerVariables. In this way, when we use the request ("parameter name") method to obtain the data submitted by the client, and the request is not used. cookie injection is generated when the data submitted by cookies ("parameter name") is filtered.

Typical Cookie injection procedure

We have introduced the knowledge of Cookie injection. Next we will look at how to determine whether a website has the Cookie injection vulnerability.

1. Search for an image like ". asp? Id = xx "class URL with parameters.

2. Remove "id = xx" to check whether the page is normal. If it is abnormal, it means that the parameter works directly in data transmission.

3. clear the browser address bar and enter "javascript: alert (document. cookie = "id =" + escape ("xx"); ", Press Enter to bring up a dialog box with the content" id = xx ", refresh the page with the original URL. If the page is displayed normally, the application uses the Request ("id") method to obtain data.

4. repeat the preceding steps to add the judgment statement in conventional SQL injection to the above URL: "javascript: alert (document. cookie = "id =" + escape ("xx and 1 = 1 "));"

"Javascript: alert (document. cookie =" id = "+ escape (" xx and 1 = 2 "));".

Like conventional SQL injection, if normal and abnormal pages are returned, the application has an injection vulnerability and can be injected with cookies.

5. Use regular injection statements for injection.

Cookie injection attack instance

Based on the above introduction, I believe that the reader has a certain understanding of the Cookie injection principle and general injection procedures. Next we will explain Cookie injection attacks through a practical case.

Our goal is this site http://knowsec.3322.org, a website I set up to demonstrate Cookie injection attacks. Let's take a look at the website page, as shown in Figure 2:

Figure 2

Let's view a piece of news, as shown in 3:

Figure 3

We learned through the URL that this is an ASP dynamic page. Now we use conventional means to detect whether the website has the SQL injection vulnerability. For the introduction and use of SQL Injection Vulnerabilities, please refer to this article (http://www.rising.com.cn/newsletter/news/2012-05-24/11580.html. First, we add a single quotation mark to the parameter value, and then submit the request. The prompt "Please do not include illegal characters in the parameter to try to inject" is displayed, and our IP address is recorded. At this time, you can confirm that the website has added an anti-injection program to filter frequently used characters in SQL injection, as shown in Figure 4:

Figure 4

Then we try again with the classic and 1 = 1 and 1 = 2, and the results are filtered out, as shown in Figure 5 and figure 6:

Figure 5

Figure 6

It seems that the conventional method for detecting SQL injection vulnerabilities cannot bypass anti-injection programs. Are there any other solutions? The answer is yes. Let's try it using the following method.

1. We put the URL above (http://www.bkjia.com/onews. asp? Id = 33) Remove the parameter following the question mark and access this page. A database error is prompted, as shown in figure 7.

Figure 7

2. now, clear the browser address bar and enter "javascript: alert (document. cookie = "id =" + escape ("33"); ", Press Enter to submit. A dialog box is displayed, as shown in figure 8.

Figure 8

3. Now let's access this URL (http://knowsec.3322.org/onews.asp) and find that it can be accessed normally, as shown in 9.

Figure 9

4. According to the results returned above, the website obtains the parameter values submitted by the browser in a way similar to owen = request ("id.

5. We can include and 1 = 1 and 1 = 2 in the preceding statements to determine whether the SQL injection vulnerability exists, such as 10 and 11.

Figure 10

Figure 11

6. Now we can determine that the website has an injection vulnerability and can be injected through cookies.

Because manual Cookie injection is cumbersome and inefficient. After understanding the principles of Cookie injection, we can use tools to improve efficiency. First, we need to use Cookie injection to generate a transit page. Let's take a look at the interface and usage of this tool, 12.

Figure 12

We take URL (http://knowsec.3322.org/onews.asp? Id = 33) to demonstrate the usage of the tool. Switch to the COOKIE injection item, enter "id =" in "injection key name", and enter "Priority" in "injection URL address" and "Source Page. As shown in Figure 13:

Figure 13

After completing all the items, select "generate ASP". Then an ASP transit page will be generated under the same directory as the tool. Upload the page to an ASP space. Here I put it on a machine that supports ASP script parsing. Now let's access http: // 192.168.30.128/jmCook. asp? Jmdcw =.

Figure 14

OK. Now we can construct the injection statement according to the conventional method. Here I put it directly in the D injection tool to run, and soon the result is returned, 15.

Figure 15

Now we have successfully obtained the Administrator's account and password. The password is encrypted, but it is easy to crack. the encryption algorithm is to add the ASCII value of each character in the password to the value of the corresponding digits, then convert to the corresponding character. The password of the root account is decrypted to 654321. As this article explains Cookie injection, the WebShell process will not be described later. If you are interested, please refer to other materials.

Summary of Cookie injection defense

We have discussed Cookie injection attacks from the attacker's perspective through a practical case above, but our goal is not to attack others, but also to better defend against attacks. As the saying goes, "Know yourself, know yourself, and know what the enemy is." Only by understanding how attackers attack can we defend more effectively.

Now we have reinforced the website programs used in the above case to discuss in detail how to resolve Cookie injection attacks. First, let's look at the code on the vulnerability page, as shown in 16.

Figure 16

Through the above code, we can know that the server did not perform any processing after obtaining the value of the parameter id, and directly brought it into the SQL statement to execute the query, thus resulting in an SQL injection vulnerability.

However, the program adds an anti-injection program to filter the data submitted through the GET and POST methods. For details, refer to the code, as shown in figure 17, figure 18, and Figure 19:

Figure 17

Figure 18

Figure 19

By analyzing the above Code, we have determined the cause of Cookie injection. The website program obtains the data submitted by the client through request ("id") and does not filter the data submitted by request. cookies in the anti-injection program.

Now we have found the root cause of the problem. How can we fix this vulnerability? There are two solutions: 1. Specify the data submission method when obtaining the data submitted by the client. You can use Request. QueryString ("id") to obtain the data submitted by GET. 2. Modify the anti-injection program and add filtering methods for Request. Cookies ("id") data submission.

Here we use the first method to modify the website code, which is actually very simple. You only need to modify the code. The modified code is as follows. For details, refer to 20:

Figure 20

Upload the modified Code to the website server and replace the old file. Now let's take a look at whether Cookie injection can be used, 21.

Figure 21

We can see that the Cookie cannot be injected and the vulnerability is fixed.