Web offensive and defensive series of cookies injected into combat

Absrtact: With the development of network security technology, SQL injection as a popular attack mode is known by more and more people. Many websites also protect SQL injection, and many webmasters do so by adding an anti-injection program. At this time we use conventional means to detect the site's SQL injection vulnerability will be blocked by the anti-injection program, what should we do in this situation? Is there no way out? The answer is in the negative.

With the development of network security technology, SQL injection as a popular attack way is more and more people know. Many websites also protect SQL injection, and many webmasters do so by adding an anti-injection program. At this time we use conventional means to detect the site's SQL injection vulnerability will be blocked by the anti-injection program, what should we do in this situation? Is there no way out? The answer is in the negative.

We know that the general anti-injection program is based on the "blacklist", according to the character string to filter out some dangerous characters. In general, the blacklist is unsafe and it has the risk of being bypassed. For example, some anti-injection programs only filter the data submitted via get, post, and the data submitted via cookies are not filtered, what should we do? In this article you will find the answer.

Cookie Injection principle

The cookie was first proposed by Netscape (Netscape), which is defined in the official document of Netscape: A cookie is a way for a server or script to maintain information on a client workstation under the HTTP protocol.

Cookies are widely used, and cookies are often seen in the web. It is often used to identify users and to track session, the most typical application is to save the user's account number and password to automatically log on to the website and e-commerce site "Shopping cart."

Cookie injection is simply an injection attack that is initiated using cookies. Essentially, there is no difference between a cookie injection and a traditional SQL injection, both of which are injected into the database, but in a slightly different form.

To learn more about the causes of cookie injection, you must understand the request object in the ASP script. It is used to obtain data submitted by the client. Let's take a look at the description of the request object in the ASP development documentation, as shown in 1:

Figure 1

The request object is typically used in this way: request. [Collection name] (parameter name), such as to get the data submitted from the form can be written as: Request.Form ("parameter name"), but the provisions of the ASP can also omit the collection name, directly in such a way to obtain data: request ("parameter name"), When obtaining data in such a way, the ASP rules are to obtain data in the order of QueryString, Form, Cookie, ServerVariables. Thus, when we use the request ("parameter name") method to obtain the data submitted by the client, and the data submitted using Request.Cookies ("parameter name") is not filtered, the cookie injection is generated.

Typical steps for Cookie injection

Above we have introduced the knowledge of cookie injection, let's look at how to determine whether a website has a cookie injection vulnerability.

1. Look for a URL with parameters that are shaped like the ". Asp?id=xx" class.

2. Remove "id=xx" to see whether the page display is normal, if not normal, the parameter in the data transfer is directly in effect.

3. Clear the browser address bar, enter "Javascript:alert (document.cookie=" id= "+escape (" xx "),", press ENTER to pop up a dialog box, the content is "id=xx", and then refresh the page with the original URL, If the display is normal, the application obtains the data in this way as request ("id").

4. Repeat the above steps to bring the judgment statement from the regular SQL injection into the URL above: "Javascript:alert (document.cookie=" id= "+escape (" xx and 1=1 ");"

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

As with regular SQL injection, if you return normal and unhealthy pages separately, there is an injection vulnerability in the app and cookie injection is possible.

5. Use regular injection statements to inject.

Example of a cookie injection attack

Through the above introduction, I believe that the reader of the principle of cookie injection and the general injection process have a certain understanding, then we will use a practical case to explain the cookie injection attack.

Our goal is to http://knowsec.3322.org this station, which is a website I built to demonstrate a cookie injection attack. First look at the site page, 2:

Figure 2

Let's take a look at a piece of news, 3 shows:

Figure 3

Through the URL we learned that this is an ASP dynamic page, now we use the usual means to detect whether the site has a SQL injection vulnerability. The introduction and use of SQL injection vulnerabilities can be consulted in this article (http://www.rising.com.cn/newsletter/news/2012-05-24/11580.html), which is not covered here. We first add a single quotation mark after the parameter value, and then submit it, and find the hint "please do not include illegal characters in the argument" and record our IP address. At this point you can be sure that the site has added an anti-injection program, filtering the characters that are often used in SQL injection, as shown in 4:

Figure 4

Then we try again with the classic and 1=1 and and 1=2, and the discovery is filtered out, such as 5 and Figure 6:

Figure 5

Figure 6

It seems that our general approach to detecting SQL injection vulnerabilities cannot bypass the anti-injection program. Do we have any other options? The answer is yes, we use the following method to try.

1. We remove the parameters after the above URL (http://knowsec.3322.org/onews.asp?Id=33) question mark, and then access the page, prompting the database error, 7.

Figure 7

2. Now we empty the browser address bar, enter "Javascript:alert (document.cookie=" id= "+escape (" 33 "));", press ENTER to submit, a dialog box will pop up, 8 shows.

Figure 8

3. Now we will visit this URL (http://knowsec.3322.org/onews.asp), we can see the normal access, 9 shows.

Figure 9

4. Based on the results returned above, the Web site is using a similar owen=request ("id") method to obtain the parameter values of the browser submission.

5. And so on, we can bring the and 1=1 and and 1=2 into the above statement to determine if there is a SQL injection vulnerability, 10, and Figure 11.

Figure 10

Figure 11

6. We can now confirm that the site has an injection vulnerability and that it can be injected via cookies.

Manual cookie injection is cumbersome and less efficient. After understanding the principle of cookie injection, we can use tools to improve efficiency. First we need to use cookies to inject a relay tool to generate a transit page. Let's take a look at the gadget's interface and how to use it, 12.

Figure 12

We demonstrate the use of the tool with a URL (http://knowsec.3322.org/onews.asp?id=33). To switch to the cookie injection, enter "id=" at "Injected Key name", "http://knowsec.3322.org/onews.asp" at "Injection URL address" and "source page", "normal cookie value" without modification, " The value after the post commit value "jmdcw=" is modified to 33. As shown in 13:

Figure 13

After the items are filled out, select "Generate ASP" and then generate an ASP brokered page in the same directory as the tool. Upload the page to an ASP space, where I put it on a machine that supports ASP script parsing. Now let's take a look at what http://192.168.30.128/jmCook.asp?jmdcw=33,14 shows.

Figure 14

OK, you can access it normally. It is now possible to construct injection statements in the usual way to inject them. Here I put it directly into the D injection tool to run, and soon returned the result, 15.

Figure 15

Now we have managed to get the administrator's account number and password, the password is encrypted, but it is easy to crack, encryption algorithm is the password of each character of the ASCII code value plus the corresponding number of digits, and then converted to the corresponding characters. The password for account root is decrypted after 654321. Since this article is about cookie injection, the process behind taking Webshell will no longer be described, if interested can refer to other materials.

Cookie Injection Defense Summary

Above we use an attacker's perspective to describe a cookie injection attack in an actual case, but our goal is not to attack others, but to better defend. As the saying goes, "know the Enemy, Baizhanbudai," only understand how the attackers attack, we can more effectively defend.

Now we have used in the above case to strengthen the site program to discuss how to resolve the cookie injection attack, first look at the vulnerability page code, 16 shows.

Figure 16

We can tell from the above code that the server side does not do any processing after getting the value of the parameter ID, and executes the query directly into the SQL statement, thus creating a SQL injection vulnerability.

However, due to the program added anti-injection program, the data submitted by the GET, post is filtered, specifically to see the code, 17, Figure 18 and Figure 19:

Figure 17

Figure 18

Figure 19

By analyzing the above code, we determine the cause of the cookie injection. The website program obtains the data submitted by the client via the request ("id") and does not filter the data submitted by the Request.Cookies method in the anti-injection program.

Now that we have found the root of the problem, how can we fix this loophole? There are two workarounds: first, to specify how data is submitted when the client submits the data, you can use the Request.QueryString ("id") method to get the data submitted through the Get method. Second, modify the anti-injection program, increase the request.cookies ("id") data submission method of filtering.

Here we use the first method to modify the site code, in fact, it is very simple, just need to modify a sentence code. The modified code is like this, specifically look at 20:

Figure 20

Upload the modified code to the Web server and replace the old file. Now let's see if we can use cookie injection, 21.

Figure 21

We can see that it is now impossible to inject through cookies, and the vulnerability is fixed.

Source: Rising Net

Web offensive and defensive series of cookies injected into combat