I. 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:
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: a_lert (1 ).
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.
Trapping 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:
<Html>
<Body>
<? Php
If (isset ($ _ GET {UserInput })){
$ Out = the entered content is: ". $ _ GET {UserInput }.".;
} Else {
$ Out = <form method = "GET"> enter the following content here :;
$ Out. = <input name = "UserInput" size = "50">;
$ Out. = <input type = "submit">;
$ Out. = </form>;
}
Print $ out;
? >
</Body>
</Html>
When we input UserInput, we print out any input <things>
Imagine the following input: script> a_lert (1) </script>, body onload = a_lert (1), img src = x onerror = a_lert (1)> or something else to inject JavaScript code into this page
What happened?
Yes .. Is it interesting?
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> a_lert (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> a_lert (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: a_lert (1 ));
So he can use it in Firefox:
1: expression_r (a_lert (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: a_lert (1)
For Visual Basic enthusiasts, you can use the following methods:
Vbscript: MsgBox (1)
Firefox does not accept background: url () with JavaScript: protocol handler (). However, Firefox allows JavaScript to be executed as an expression. In Firefox, set USERINPUT3A to the following values:
); 1: expression_r (a_lert (1)
USERINPUT4 can be used directly, as long as USERPINUT4 is set:
"; A_lert (1 );
USERINPUT5 is deeply embedded into JavaScript. To insert (ensure that the executed) a_lert (1) function, you must put a_lert (1) out of all code blocks and ensure that the front and back of JavaScript code are legal, as shown below:
) {} A_lert (1); if (0)
The text before A_lert (1) completes the original if statement, so that the_lert (1) function is always executed. The text after a_lert (1) creates an if statement for the remaining code blocks, so all the code between the script labels is legal JavaScript code. Otherwise, JavaScript cannot be interpreted and executed due to syntax errors.
You can use some tricks to inject JavaScript into USERINPUT6. For example, you can use the following method:
"> <Script> a_lert (1) </script>
Alternatively, if angle brackets are not allowed, a JavaScript event handler, such as The onclick event handler, is used as follows:
"Onclick =" a_lert (1)
USERINPUT7 can also be like this:
> <Script> a_lert (1) </script>
Or:
Style = x: expression_r (a_lert (1 ))
It is even simpler:
Javascript: a_lert (1)
The first two methods of USERINPUT7 ensure that the script is executed when loading the page. The last method requires the user to click the link. You can try them all to see if some characters and strings are not allowed in some cases.
USERINPUT8 also faces similar HTML injection strings. The following is the best way to use the event handler:
NotThere); a_lert (1 );
And:
X); a_lert (1)
Finally, USERINPUT10 can be used by the event handler to break through the input tag. The example is as follows:
X onclick = a_lert (1)
This example shows that the string provided by the user can be stored anywhere in the HTTP response. It seems that everything is possible!
If you have successfully performed HTML injection in any of the preceding instances, the HTML injection can be used for XSS anywhere on that domain. You can inject JavaScript into Web applications in multiple ways. If your attempt has damaged the page format, such as page truncation and displaying scripts other than your injection, you may have found an XSS vulnerability.
Iv. Reflection HTML injection in the redirector
Another major stage of HTML injection is the redirection. Some redirections allow users to redirect to any URL. Unfortunately, JavaScript: a_lert (1) is a legal URL. Many redirector will parse the URL to determine whether the redirection is secure. These parsers and their programmers are not always as intelligent as people think, so they are like the following URL:
Javascript: // www.anywhere.com/%0da_lert (1)
And this:
Javascript: // The http://www.trustedsite.com/trustedDirectory/%0da_lert (1)
It may be accepted. In the preceding example, any string can be placed between the two slashes used by the JavaScript annotation and between the URL-encoded line breaks (% 0d.
5. HTML injection in mobile applications
Some popular Web applications have been transplanted to the mobile communication field. These mobile applications generally have the same functions, but the security features are even worse, and they can still be accessed through browsers such as IE and Firefox. Therefore, they are ideal targets for HTML injection attacks and cross-site request forgery.
Generally, mobile applications run in the same domain as the main Web applications, so any HTML injection in mobile applications can access the entire domain, this includes the main Web applications running on the domain or other Web applications.
6. HTML injection in Ajax response and error message
Not all HTTP responses are displayed to users. Pages like AJAX responses and http Error messages are often ignored by developers. Developers may not consider providing HTML Injection Protection for AJAX responses because these requests are generally not directly used by users. However, attackers can use previous code snippets to simulate ajax get and POST requests.
Similarly, Hypertext Transfer Protocol (http) Error responses, such as HTTP 404 (Not Found) and HTTP 502 (Server Error), are usually ignored by developers. Developers tend to assume that everything is HTTP 200 (OK ). You can try to trigger other responses, instead of just HTTP 200, and then try to inject the script.
7. Use UTF-7 encoding for HTML Injection
If the user's IE automatically selects the intent set, attackers can avoid most HTML injection prevention measures. As mentioned above, prevention measures for HTML injection generally rely on escaping potentially harmful characters. However, UTF-7 encoding technology uses generic characters that cannot be properly escaped, and these generic characters sometimes cannot be exchanged by some Web applications. The UTF-7 escape version of will look like the following:
+ ADw-script + AD4-a_lert (1) + ADw-/script + AD4-
Note that this is an uncommon attack because users generally do not enable the auto-selection encoding technology option. Of course, it also exists
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
