To test whether a cross-site scripting vulnerability exists in a Web application

So far, there is no objection to the threat of Cross-site scripting attacks. If you are proficient in XSS and just want to see what good testing methods are available, skip to the test section of this article. If you don't know anything about it, please read it in order! A cross-site scripting attack occurs if a malicious person (an attacker) can force an unsuspecting user (the victim) to run an attacker's chosen client script. The term "Cross-site scripting" should be a misnomer because it is not just about scripting, it's not even necessarily cross-site. So, it's a name that comes up when this attack is discovered, and it has been in use ever since. From now on, we'll use its common abbreviated name "XSS".

The process of XSS attacks involves the following three parties:

• Attackers

• victims

• Vulnerable Web sites (attackers can use it to act against victims)

Of these three parties, only the victim would actually run the attacker's code. Web sites are simply a vehicle for launching an attack and are not generally affected. XSS attacks can be initiated in a variety of ways. For example, an attacker could send a maliciously crafted malicious URL to the victim via e-mail, IM, or other means. When the victim opens the URL in a Web browser, the Web site displays a page and executes the script on the victim's computer.

Testing XSS Vulnerabilities

I've been a full-time security advisor for years, and I've done this countless times. I boil down the good test plan to two words: thorough. For you and me, finding these vulnerabilities has nothing to do with having the opportunity to boast about Bugtraq or vulnwatch, and it only has to do with how well the job is done. If this means checking all the individual query string parameters, cookie values, and POST data values in the application, this can only indicate that our work is not too daunting.

Obviously, a complete security check involves much more than just finding an XSS vulnerability, and it needs to build a whole threat model, test overflow vulnerabilities, information leaks, error handling, SQL injection, authentication, and authorization errors. The good news is that there is overlap between areas in the execution of such a thorough work. For example, when testing an XSS vulnerability, it is common to identify error handling or information disclosure issues.

I assume you belong to a team that is responsible for developing and testing your WEB application. In this fortunate position, you can mix black box and white box methods. Each method has its own advantages, and can even support each other when used in combination.

1. Prepare your kit in sequence

The test work can also be automated, but we only discuss manual operations here. The prerequisite tools for manual testing include:

Paros Proxy (http://www.parosproxy.org) for intercepting HTTP traffic data

fiddler (Http://www.fiddlertool.com/fiddler), for intercepting HTTP traffic data

burp Proxy (http://www.portswigger.net/proxy/)

Tamperie (Http://www.bayden.com/dl/TamperIESetup.exe), for modifying get and POST

We have listed at least three kinds of WEB proxy software. You can also look for a different kind of product, because each product has its own uniqueness. Below, you need to intercept these requests before the Web browser makes HTTP requests and modify them to inject the XSS test code. All of these tools can accomplish this task, and some tools will also display the returned HTML source code (if you choose to intercept the server response).

It is important to intercept the get and POST requests made by the client. This will bypass all client JavaScript input validation code. I'm here to remind all WEB developers that client-side security controls are unreliable. Validation should always be performed on the server side.

2. Identify sites and their functions-communicate with developers and PM

Draw some simple data flow diagrams to describe the pages and their functions on the site. At this point, you can schedule some meetings with developers and project managers to build a threat model. Try to delve into the application as much as possible at the meeting. Does the site expose Web services? Is there an authentication form? Do you have a message board? Is there a user settings page? Make sure that all of these pages are listed.

3. Identify and list all the points provided by the user input

Further refine the site map. I usually create a spreadsheet for this. For each page, lists all query string parameters, cookie values, custom HTTP headers, post data values, and user input that is passed in other forms. Don't forget to search for WEB services and similar SOAP requests, and find all the fields that allow user input.

List each input parameter separately, because you need to test each parameter independently. This is probably the most important step! If you read the following spreadsheet, you'll see that I've found a whole bunch of these things in the sample site. Query strings such as Forwardurl and Lang. such as name, password, msgbody, Msgtitle, and such POST data, even some Cookie values. All of these are important test items that we are interested in.

4. Think carefully and list test cases

Use the resulting spreadsheet to tie out various methods used to test for XSS vulnerabilities. We'll discuss the various methods later, but let's take a look at the screenshot of my spreadsheet first, and notice that I have listed each value allowed on the page and all the test types for each value. This method of recording tests is only my own habit, you can use your own method. I like to record everything so that I can know what work has been done and what work has not been done.

5. Start testing and pay attention to output results

The most important part of finding a vulnerability is not whether you have found a vulnerability. It's about whether you really know what's going on. For XSS, just check the HTML output and see where the content you entered is. Is it in an HREF tag? Is it in the IFRAME tag? Is it in the CLSID tag? In the IMG SRC? What is the PARAM NAME of some Flash content?

I'll check all of these and if you know the purpose of what you're typing, you can adjust your tests to find out what's wrong. This means you may need to add an extra enclosing bracket ">" to make a tag complete, or add a double quote to close an element within the tag. Alternatively, you might want to encode your characters using URLs or HTML, such as turning double quotes into%22 or.

6. Well, not so easy, this site seems to be relatively tight. What should we do now?

Well, perhaps your simple test case <script>alert (' Hi ') </script> does not produce the desired warning dialog box. Think about the problem and communicate with developers where possible. Perhaps they filtered the angle brackets, single quotes, or parentheses in the input. Maybe they'll filter the word "script." Re-examine why input produces such output and understand the role of each value (query string, cookie, POST data). Query string values such as "pageid=10" may have no effect on the output, so it is not worth the time to test it. Sometimes it's best to try to inject a single character (such as angle brackets, double quotes, or parentheses) to see if the application filters the characters. Then you can see exactly what level of filtering you are facing. You can then adjust the test methods, encode the characters and try again, or look for other injection methods.

Changing test Cases

I'm afraid I can't fully explain this: it's important to study what HTML pages are exported by the value of the input. If they can't produce output, don't waste time on them. If you can, do research, because you need to modify the tests according to the output. I used various forms of change to find the parameters that would accept and display the script code. Because it involves too much content, there is no discussion here, but it is important to note the following:

1.> "' ><script>alert (' XSS ') </script>

2.>%22%27>

3.> "' >

4.ak%22%20style%3d%22background:url (Javascript:alert (%27xss%27))%22%20os%22

5.%22%2balert (%27xss%27)%2b%22

6.<table background= "Javascript:alert ([code])" ></table>

7.<object type=text/html data= "Javascript:alert ([code]);" ></object>

8.<body onload= "Javascript:alert ([code])" ></body>

There are many forms of change that can be tried. The key is to understand exactly how the program handles input and display output pages. As these examples show, common variations are often preceded by a ">" in front of the scripting code to try to close the markup that a Web site might generate in the output. You can also URL-encode code to try to bypass the server-side input filtering function. In addition, because the angle bracket "<>" is usually filtered and removed from the output when it is entered, you must also try an XSS that does not require angle brackets, such as "&{alert (' XSS ')};"

Persistent and dynamic

Finding a successful XSS is a lot of trouble, because XSS attacks may not be as obvious at first. As an example, if you add a new message to the Web site and inject code into the "Msgtitle" value, you may not see the script code executed immediately after submitting the data. However, when you access the message board, the "Msgtitle" value is used in the HTML page and executed as script code. This is known as a persistent XSS attack, which can occur if the value containing the script code is saved to the client or back-end system and executed at a later time.

The opposite of this is a dynamic XSS attack, which is executed immediately and occurs only once. For example, if a link or GET request contains scripting code in a query string that controls the output of a page, the output is displayed immediately after clicking the link.

Summarize

XSS testing is often a small part of the security review of the entire WEB application, but it must be detailed and thorough in the execution of tests. For years, I've emphasized that using spreadsheets or other methods to record all pages of a site, as well as the input values that each page accepts (query strings, cookies, POST data, SOAP), is an important step that must be taken before testing. It is equally important to understand the input and how it renders on the output HTML page. If you know how your application processes input, you can do a lot of work very quickly. Don't waste time testing the input that won't be shown as output. Communicate with developers and PM and build a sophisticated threat model before you start testing.

What is an XSS vulnerability?

As a web developer or tester, you certainly know that the technical underpinnings of Web applications are made up of HTTP and HTML. The HTTP protocol is the transport mechanism for HTML, which allows you to design Web page layouts and build pages using code.

If the WEB application accepts input information submitted by a user through an HTTP request, such as Get or POST, and then uses the output HTML code to display the information in some places, an XSS vulnerability may exist. Here is one of the simplest examples:

1. The WEB request looks like this:

Get Http://www.somesite.com/page.asp?pageid=10&lang=en&title=Section%20Title

2. After the request is made, the HTML content returned by the server includes:

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 side (since it is always possible to bypass the client control), then a malicious user can use a number of means to abuse the vulnerability:

Attackers can inject code by getting rid of

Http://www.somesite.com/page.asp?pageid=10&lang=en&title=Section%20Title

The HTML output for this request will be:

Even in this simplest example, an attacker can use this connection to accomplish countless things. Let's look at the potential threats and discuss some of the more advanced test methods.

How serious is the threat of XSS attacks?

Because of the ability to inject code into a generated Web page, the threat you can think of is so serious that it can be a serious threat. Attackers can use XSS vulnerabilities to steal cookies, hijack accounts, execute ActiveX, execute Flash content, force you to download software, or take action on hard disks and data.

This can happen as long as you click on certain URLs. How many times a day do you click a URL in a message board or newsgroup when you are reading a trusted e-mail message?

Phishing attacks typically use XSS vulnerabilities to dress up as legitimate sites. You can see many of these situations, such as your bank sending you an email, informing you of some changes to your account and enticing you to click on certain hyperlinks. If you look closely at these URLs, they can actually take advantage of vulnerabilities in the bank's web site, which are similar in form to Http://mybank.com/somepage?redirect=<script>alert (' XSS ') </ Script>, where the "redirect" parameter is used to execute the attack.

If you are cunning enough to target an administrator, you can send a message with the following topic: "Help!" The address of this website always appears to be wrong! "After the administrator opens the URL, you can perform many malicious actions, such as stealing his or her credentials."

Well, now that we have understood its harmfulness--harm the user, harm the administrator, bring bad public image to the company. Now, let's take a look at the focus of this article--testing your Web site for these issues.