Test whether the Web application has the cross-site scripting vulnerability.

So far, we have no objection to the threat of cross-site scripting attacks. If you are proficient in XSS and want to see what test methods are available for reference, skip to the test section in this article. If you do not know anything about this, please read it carefully in order! If a malicious user (attacker) can force an uninformed user (victim) to run the client script selected by the attacker, a cross-site scripting attack will occur. The word "cross-site scripting" should be inappropriate because it is not only related to scripts, but also not necessarily cross-site scripting. Therefore, it is a name that begins when such an attack is discovered and remains in use until now. From now on, we will use the common abbreviation "XSS ".

The XSS attack process involves the following three aspects:
• Attackers
• Victims
• Websites with vulnerabilities (attackers can use it to take actions against victims)

Among the three parties, only the victim will actually run the attacker's code. Websites are only a carrier of attacks and will not be affected. XSS attacks can be initiated in multiple ways. For example, an attacker can send a maliciously crafted malicious URL to the victim via email, IM, or other means. When the victim opens the URL in a Web browser, the website displays a page and executes the script on the victim's computer.

What is an XSS vulnerability?
As a Web developer or tester, you must know that the technical basis of Web applications is composed of HTTP and HTML. HTTP is the transmission mechanism of HTML. You can use code to design Web page layout and generate pages.

If the Web application accepts the input information submitted by the user through an HTTP request (such as GET or POST) and then displays the information in some places using the output HTML code, an XSS vulnerability may exist. The following is a simple example:

1. The Web request is as follows:
GET http://www.somesite.com/page.asp? Pageid = 10 & lang = en & title = Section % 20 Title

2. After a request is sent, the server returns the following HTML content:
<H1> Section Title

As you can see, user input passed to the title query string parameter may be saved in a string variable and inserted into the

3. Now, if the site does not filter user input on the server (because the client control can always be bypassed), malicious users can abuse the vulnerability by many means:

Attackers can inject code by getting rid of the