Testing a Web application, whether there is cross-site scripting vulnerability-vulnerability warning-the black bar safety net

2007-02-26T00:00:00
ID MYHACK58:62200714265
Type myhack58
Reporter 佚名
Modified 2007-02-26T00:00:00

Description

So far, for cross-site scripting attack has the very big threat that we no objection to it. If you are proficient with XSS and just wanted to see what test methods are available to draw on, then please skip directly to the article of the test section. If you know nothing about this, follow the sequence carefully read! If a malicious person, the attacker, can force an unknowing user, the victim runs the attacker's choice of client-side script, then it will occur a cross-site scripting attacks.“ Cross-site scripting”this word should belong to the misnomer of the situation, because it is not only with the script, but it is even not necessarily is cross-site. So, it is the one found in this attack when a name, and has been in use ever since. From now on, we will use the common abbreviation of the name “XSS to”.

XSS attack the process involves the following three parties: ? The attacker ? Victims ? Vulnerable website an attacker can use it to victims of action

In this third party, only the victim will actually run the attacker's code. Website only be initiated by the attack of a carrier, generally will not be affected. Can be used in a variety of ways to initiate XSS attack. For example, the attacker via e-mail, IM or other means to a victim to send a through the Center to construct a malicious URL. When the victim in a Web browser to open the URL at the right time, the website will display a page and on the victim's computer executing the script.

XSS vulnerability is what kind of? As a Web Developer or tester, you must know the Web application of the technical base is composed of HTTP and HTML. The HTTP Protocol is the HTML of the transport mechanism, you can use the code to design Web page layout and to generate the page.

If the Web application accepts the user through the HTTP request such as GET or POST to submit the input information, and then use the Output HTML code in certain places to show this information, there may be XSS vulnerabilities. The following is one of the most simple example:

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

2. After issuing the request, the server returns the HTML content comprises: <h1>Section Title</h1>

You can see that is passed to the“title”query string parameter of the user input may be stored in a string variable and by the Web application is inserted into the <h1> tag. By providing an input content, an attacker can control the HTML.

3. Now, if the site is not on the server side to the user input to be filtered as you can always bypass client side controls, then a malicious user can use many tools for this vulnerability to be abused:

The attacker can get rid of the <h1> tag to inject code: http://www.somesite.com/page.asp?pageid=10&lang=en&title=Section%20Title</h1><script>alert(‘XSS%20attack’)</script>

This request is the HTML output will be: <h1>Section Title</h1><script>alert(‘XSS attack’)</script>

Even this most simple example, the attacker can also use this connection to complete numerous things. Let us look at what are the potential threats, and then discuss some of the more advanced testing methods.

XSS the threat of attack how serious is it? Since it is possible in the generated Web page, the injected code, can think of the threat of how serious, you can how serious the threat. An attacker can use XSS vulnerabilities to steal Cookies, hijack the account, execute the ActiveX implementation of the Flash content, forcing you to download the software, or to the hard disk and the data to take action.

As long as you click some URL, all of this will happen. Every day, in the reading from message boards or newsgroups of trusted e-mail at the right time, you will how many times to click where the URL is?

Phishing attacks typically use XSS vulnerabilities to dress up as a legitimate site. You can see many such situations, for example your Bank sent you an email to inform you of your account to make some changes and induce you to click on certain hyperlinks. If you look closely at these URLS, they may actually use the Bank's website in the presence of vulnerabilities, their form is similar to the http://mybank.com/somepage?redirect=<script>alert(‘XSS’)</script>, here the use of the“redirect”parameter to perform the attack.

If you have enough cunning, you can be the administrator designated as an attack target, you can send an email with the following subject of the mail:“distress it! The website address always occurs error!” The administrator opens the URL, you can perform many malicious actions, such as steal his or her credentials.

Well, now that we have understood its harm -- harm to users, harm to the administrator, giving the company a bad public image. Now, let's look at the focus of this article-a test of your site whether the presence of these problems.

Testing XSS vulnerability Over the years, I've been a full-time security consultant, has done countless such tests. I will be a good test plan boils down to two words: completely. For you to say, find the vulnerabilities and be able to have the opportunity in Bugtraq or Vulnwatch boasting some there is no relationship; it only with how well done responsible work related. If this means that the application in all of the individual query string parameters, cookie values and POST the data value is checked, then this only shows that our work is not too arduous.

Obviously, a complete security check of the content involved is usually far beyond looking for XSS vulnerabilities as simple as that; it needs to establish the overall threat model, the test overflow vulnerability, information leakage, error handling, SQL injection, authentication, and authorization errors. Fortunately, the implementation of such thorough work, in various fields between the presence of overlap. For example, in the test XSS vulnerabilities, often in conjunction with when find out the error handling or information leakage issues.

I suppose you belong to a is responsible for Web application development and testing teams. In this lucky position, you can use a mixture of black box and white box method. Each method has its own advantages, when used in conjunction even be able to provide mutual support.

  1. In order to prepare your Toolkit Test work can also be automated, but here we discuss only the manual operation. Manual testing essential tool comprising: ? Paros proxy ( http://www.parosproxy.org ), is used to intercept the HTTP communication data ? Fiddler ( http://www.fiddlertool.com/fiddler ), is used to intercept the HTTP communication data ? The Burp proxy ( http://www.portswigger.net/proxy/ ) ? TamperIE ( http://www.bayden.com/dl/TamperIESetup.exe ), is used to modify the GET and POST

We The above lists at least three Web Proxy software. You can also find various other similar products, because each product has its own unique. Next, you need to in a Web browser issuing an HTTP request before intercepting these requests, and modify them to inject XSS test code. Above all these tools can accomplish this task, some tools will display the returned HTML source code if you choose to intercept the server responses.

Intercepting the client GET and POST requests is very important. So you can bypass all client-side javascript input validation code. I'm here to remind all of the WebDeveloper-the Client Security Control is unreliable. Should always be on the server to perform the validity verification.

  1. Determine the site and its functionality-with developers and PM to exchange Draw some simple data flow diagrams of site pages and their functionality will be described. At this time, you can arrange some with the developers and project Manager's meeting to establish a threat model. At the meeting as the application for in-depth discussion. The site discloses a Web service? Whether there is authentication form? There are message boards? The user settings page? Ensure that lists all these pages.

  2. Find out and list all provided by the user input of the point The site map for further refinement. I usually do this to create a spreadsheet. For each page, list all the query string parameters, cookie values, custom HTTP headers, the POST data value and other forms of transfer of the user input. Do not forget to search Web service and is similar to the SOAP request, and find out all allows the user to enter the field.

Listed separately for each input parameter, as the following need to independently test each parameter. This is probably one of the most important steps! If reading the following spreadsheet, you will see I have in the example site to find out a whole bunch of stuff like that. Such as the forwardURL and lang such a query string. Such as name, password, msgBody, the msgTitle and so the POST data, and even some Cookie values. All of these are of interest to us the important test content.

  1. Think carefully and list the test cases Use has been get the spreadsheet lists the various used to test XSS the vulnerability of the method. We later will discuss various methods, but now let's look at my spreadsheet, Please note that I have listed on the page to allow for each value and each of values of all test types. This recording of the test method is only of my own habit, you can use your own method. I like to record all things, so that I can know already what work and what work was done.

  2. Start the test and note the output results In finding loopholes in the process, the most important part is not whether you found the vulnerability. But do you really know what happened what things. For XSS, you'll need to check the HTML output and see if you have typed in somewhere. It in the A HREF tag? Whether in the IFRAME tag? It is in the CLSID tag? In the IMG SRC? Some Flash content to the PARAM NAME is what?

I will check all these cases, if you are on the input content of the object is very understanding, you can adjust your test to find the problem. This means that you may need to add an extra closed parenthesis“>”to make a marker become complete, or add a double quote to close the tag within an element. Or, you may need to use URL or HTML encode your characters, such as the double quotation mark becomes %2 2 or".

  1. Well, not so easy, this site seems to prevent relatively tight. Now what do I do? So maybe your simple test case <script>alert(‘hi’)</script> does not produce the desired in the warning dialog box. Think carefully about this question and in the possible case with the developers. Maybe they are on the input in angle brackets, single quotation marks or parentheses were filtered. Maybe they will filter the“script”of the word. Re-research why the input will produce such output, and understood that each value of the query string, cookie, POST data.“pageId=1 0”so that the query string value may be the output is not affected, and therefore not worth spending time testing it. Sometimes, it is best to try to inject a single characters such as angle brackets, double quotation marks or parentheses, and see whether the application has filtered these characters. Then, you can know that you are facing the level of filtering exactly how. Then, you can adjust the test method, these character encoding and try again, or look for other injection approaches.

Change the test case I'm afraid I cannot fully be described: study of the value of the input will output the kind of HTML page is very important. If they can not produce output, then don't get on top of them a waste of time. If you can, do the research, because you need to according to the output of the test to be amended accordingly. I have used various changes in the form to find a can accept and display the script code parameters. Because it involves too much content, so here are unable to be discussed, but be sure to pay attention to the following several situations:

1.& gt;"'><script>alert(‘XSS')</script>

2.& gt;%2 2% 2 7><img%20src%3d%22javascript:alert(%27XSS%2 7)%2 2>

3.& gt;"'><img%20src%3D%2 6%23x6a;%2 6%23x61;%2 6%23x76;%2 6%23x61;%2 6%23x73;%2 6%23x63;%2 6%23x72;%2 6%23x69;%2 6%23x70;%2 6%23x74;%2 6%23x3a;alert(%26quot;XSS%26quot;)>

  1. AK%2 2%20style%3D%22background:url(javascript:alert(%27XSS%2 7))%2 2%20OS%2 2

5.% 2 2%2Balert(%27XSS%2 7)%2B%2 2

6.& lt;table background="javascript:alert(([code])"></table>

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

8.& lt;body ></body>

There are many variations you can try. The key lies in understanding how the program exactly use what way to process the input and display the output page. As these examples show, a common form of change is often in the script Code, Add “>””, in an attempt to closed the site may be in the output generated tags. Also can The code for the URL encoding, try to bypass the server-side input filtering. In addition, because the angle brackets“<>”usually the input is filtered and output from the output remove, so you must also try to not need angle brackets to XSS, for example, ”&{alert('XSS')};”

Durable and dynamic Find a successful XSS struggle to find, because at the beginning XSS the attack may not be so obvious. Just to give an example, if the website to add a new message and in the“msgTitle”value of the injected code, in submitting the data, you may not immediately see the script code to be executed. However, when you visit the message boards at the right time, will be in the HTML page using the“msgTitle”value and use it as a script code execution. This condition is called persistent XSS attacks, if it contains the script code value will be saved to the client or back-end system and the wait time is executed, will occur such attack.

And with this relative is dynamic XSS attack, this attack will be executed immediately and only happened once. For example, if a link or GET request in an used to control page output for a query string containing the script code, then after clicking the link will immediately display the output.

Summary XSS the test is usually just the entire Web Application Security Review of a small part, but in the test execution must be meticulous and thorough. In many years of work, I always emphasize the use of spreadsheets or other ways to record all of the site's pages, and each page to accept the input values, query string, cookie, POST data, SOAP is in the test must be carried out before an important step. With this equally important, understand the input and its output on the HTML page is rendered. If you know the application is processing the input the way, you will very quickly accomplish many work. Don't waste time testing those that do not as the output display of the input. With developers and PM to communicate, and at the beginning of the pre-test to establish a comprehensive threat model.