Using Fiddler's X5s plugin to find XSS vulnerabilities

The Crosssite Scripting (cross-site scripting attack) in the OWASP Top 10 security threat allows an attacker to inject malicious script into the Web site through a browser. This vulnerability often occurs in Web applications where user input is required, and if the site has an XSS vulnerability, an attacker could send a malicious script to the user browsing the site, and can also exploit the vulnerability to steal SessionID, which is used to hijack the session of the user account.

So the website developer must test the attack appropriately and must filter every input and output of the website. To make vulnerability detection easier, you can also use a variety of scanners, and there are many automated or manual tools that can help us find these vulnerabilities. X5s is a tool used to test XSS vulnerabilities, which is a plug-in for fiddler and a Webdebugging Proxy.

X5s is an XSS vulnerability that specializes in helping penetration testers find websites. The first point here is that the tool is not an automation tool, but a list of where XSS vulnerabilities may exist, so to use this tool, readers need to understand XSS and know what encoding could lead to an XSS vulnerability. This tool is intended for experienced penetration testers only, as they know how to insert malicious scripts with coding vulnerabilities.

In this article, we can see how to use the fiddler that contains the X5s plug-in, and how to find vulnerabilities in the Web site.

Fiddler: Fiddler is a popular webdebugging proxy tool that can monitor and record traffic between a user's PC and the Web site, which can be used to review traffic through a log file or to debug Java-and. NET-based HTTP-related applications. Of course, fiddler is free for all users.

Fiddler also supports the combination with the browser to make it easier to use. Supported browsers include IE, Googlechrome, Safari, Mozillafirefox, opera, and more.

Figure 1Fiddler shows the traffic log on the left

Readers can download Fiddler from here. In Fiddler, a number of tags can be found to analyze traffic and packet behavior. This article does not deal with the knowledge of how traffic is analyzed, mainly demonstrating the use of x5s to exploit XSS vulnerabilities.

x5s:fiddlerfiddler preamblexss vulnerability. But users need to know xss and encoding coding knowledge, because all and xss All related work should be done manually.  basically x5s is to detect where the user input is not properly encoded. Sometimes unicode character conversion may bypass Some safety filters, So this character conversion is also detected.  

The plugin looks at the request and response in the URL and then attempts to inject xsspayloads to determine if there is an XSS vulnerability. If the reader knows how to run a code somewhere, it's easy to dig into an XSS vulnerability.

In addition, the reader needs to know that the tool basically detects only reflective XSS issues, does not detect DOM-based XSS vulnerabilities, and does not detect storage-type XSS because the data for this vulnerability does not appear in the parameters of the request and response. To detect both of these vulnerabilities, the reader needs to use additional tools.

To use X5s to mine an XSS vulnerability in a Web application, you can download x5s and install it from the following connection, and remember to ensure that the Fiddler is installed before you install it:

Download X5s

After installation, start Fiddler, you can see the X5s label, as shown in:

X5s label in Figure 2Fiddler

You can see that the x5s tag has been added to the fiddler. If the reader doesn't see the watcher tag in his fiddler, Don't worry, watcher is just another plug-in for the Fiddler for XSS testing. This article is only interested in X5s and only discusses the plugin.

Configuration

We need to properly configure the x5s before we begin to exploit the XSS vulnerability. First, enter fiddler, open the X5s tab, select the Enable check box at the top, and then enter XSS in the Preamble text box. You can enter any word here, but to ensure that it is not a common word, x5s will inject each parameter in the request with that option. Next Select the check box in front of "Enabledomain name targeting" and add the domain name, where you can add all the domain names you want to test, and you can add multiple, depending on the user.

Also, don't forget to check the boxes in front of "Request" and "Responses" and select all the checkboxes under "Autoinjection Options".

Figure 3x5s Configuration

The following test case configuration

Test Case Configuration

X5s the label below there are three sub-tabs, click the second "TestCase Configuration".

Under this tab, you can configure the X5s test case, the probe character, which consists of three types:

Convertible test Cases: Probe characters may be uppercase, lowercase, and converted to other forms.  Legacy Test Cases: the characters used by XSS injections. These injected characters include ",", <, and >. Readers should already know that these characters, if not properly filtered, can be a  major problem in XSS vulnerabilities. Extra Long UTF-8 Test Cases: This test is used to inject non-shortestutf-8 encoding or traditional test cases, such as  the ASCII character < UTF-8 format is 0x3C.  

Select the characters you want to test. Here you can choose any number, or select all directly. You can then start an XSS attack and dig into the injection point.

Figure 4x5s Test Case Configuration

To demonstrate the effect, I've added a domain name that contains an XSS vulnerability. But for the sake of security, this article hides the domain name of the website.

Next, start a page to test all forms in one page and view the results of the scan in the Result tab. If the search results are displayed, there may be an XSS vulnerability in the Web site. Click one of the scan results to see a detailed description in the text area below.

Figure 5x5s XSS scan results in fiddler

Select a result, the text area below will show the detail description, such as how to add the XSS word specifier how to find preamble. View detail description and analysis, description of the Red Word section, showing the page preamble information.

The next step is to look for URLs that are suspected to contain vulnerabilities. Fiddler the URL to the left of the previous visit, all we have to do is identify the URL request that contains the vulnerability. View the record to find the request address highlighted in gray.

As shown, the URL information is hidden here for security reasons.

Figure 6 URL request with suspicious preamble information

You can see that the URL in the red box is highlighted in bright gray. Right-click on the record and select "Justurl" under Copy to copy the request URL.

Figure 7 Copy Request URL

Open the browser, copy the address to the browser, and replace the preamble character in the address with your own XSS payloads. Readers can use the following XSS payloads:

<script>Alert(1)</script>"><script>alert (1) </script ></style><script>alert ( 1) </script> </script><script>alert (1</script> "> src= "a"       onerror= "prompt" >  

In this case there are many XSS payloads available, the above payloads if a JavaScript warning box is displayed and 1 is displayed, the execution succeeds. Because the alert (1) is inserted in the payloads, a dialog box pops up to indicate that the site has executed our custom script, which means there is an XSS vulnerability in the station.

Figure 8 using fiddler and X5s to find an XSS vulnerability

The following test shows whether cookies can be displayed in the Alert dialog box, just replace alert (1) with alert (Document.cookie).

If cookies are displayed in the Alert dialog box, this is a serious vulnerability that could allow an attacker to hijack a user's sessions to hijack a user account and possibly cause damage to the user or website.

This is the simplest demonstration of using x5s to find site-reflective XSS vulnerabilities, showing the importance of x5s for penetration testers.

Why penetration testers do not use the tool

Many penetration testers do not recommend this tool, the only reason is that today there are many scanning tools integrated with a variety of scanning technology, these scanners can crawl (crawl) site all the URLs and list all the vulnerabilities found, most scanners are great. The tool can only detect reflective XSS vulnerabilities.

At the same time the tool takes longer, because we have to manually detect each URL, it is possible to miss a page containing XSS vulnerability, there is no way to detect this page, it is also possible to waste a lot of time after the software limitations did not find a vulnerability.

However, we find that many penetration testers often use the tool, which depends entirely on the tester's own choice. But I still recommend that the reader try this tool, and if it's handy, you can continue to use the tool to find XSS vulnerabilities in Web applications. As a beginner, readers can use this tool to improve their knowledge about XSS payloads, and sometimes it can take hours to exploit a suspicious vulnerability.

Summarize:

X5s is a good fiddler plug-in that can be used as a penetration test tool to find XSS vulnerabilities. However, only the basic principles of XSS are understood, and how many methods exist to inject JavaScript code before using the tool. If the user is not good at manual XSS testing, the tool is undoubtedly a chicken. But for professional XSS testers, using this tool may be the quickest way to find XSS vulnerabilities for Web apps. The example in this article shows that the tool finds all the suspicious hotspots (hotspots) that may have an XSS vulnerability, and the user only needs to test those hotspots and confirm where the external script can be executed, which is successful if it can be injected. Otherwise, continue the test until all XSS payloads have been tested. Only experienced penetration testers can confirm that a suspicious web site has an XSS vulnerability, because they can better understand the output of the Web application and the payloads of the injected behavior feedback.

We already know that using this tool requires considerable experience, and it takes a lot of time to open each URL to detect all of its forms to detect the existence of an XSS vulnerability, which is a time-consuming process. And these things are automatically done in the automatic vulnerability scanner, making the tool only a handful of researchers and testers, but it can still be a good start.

Original address:http://resources.infosecinstitute.com/using-x5s-with-fiddler-to-find-xss-vulnerabilities/

Using Fiddler's X5s plugin to find XSS vulnerabilities