Using X5S with Fiddler to find XSS Vulnerabilities

Cross Site Scripting is one of the top 10 OWASP security threats. This dangerous vulnerability allows attackers to inject malicious scripts on a website in using the browser. This flaw can be found anywhere inside the application that takes users inputs. If the website is vulnerable to XSS, attackers can send malicious scripts to users. It can be used to steal session ids and thus hijack active sessions of user accounts.

So website developers must test their website properly against this attack. They must validate each input and sanitize outputs everywhere on the site. For finding XSS vulnerabilities on website, they can also use various available scanners that easily find XSS and other vulnerabilities. There are many automatic and manual tools available that helps in finding those vulnerabilities. X5S is also a similar kind of tool that is used to test XSS vulnerability. It is an add-on for Fiddler, a Web Debugging Proxy.

X5S is designed for penetration testers to help in finding Cross Site Scripting vulnerabilities in web applications. Now, there is an important thing I want to note down here that the tool is not an automatic XSS finding tool. It only lists where the possibilities of XSS are. So you need to be good in XSS and understand how poor encoding issues can lead to XSS in order to use the tool successfully. This tool is for experienced penetration testers only because they know how to exploit poor encodings to inject client side scripts.

In this detailed post, we will see how to use Fiddler with X5s and find XSS vulnerabilities in websites.

Fiddler: Fiddler is a popular web debugging proxy tool that monitor and log the traffic between your computer and the website you are surfing on browsers. So you can inspect the traffic by using the log files. This tool can also debug Java and .NET based applications that use win HTTP. Fiddler is available for free for all users.

It also supports the available browsers so it can be used easily. Supporting browsers includes Internet Explorer, Google Chrome, Safari, Mozilla Firefox, Opera, and more.

Picture 1: Fiddler Screen showing Traffic Logs at the left side

You can download Fiddler Here Download Fiddler

In fiddler, you will find many tabs that will allow you to analyze the traffic and packers behavior. Here, I am not going to explain how to analyze traffic because the main focus of the article is to show Cross Site Scripting Vulnerability with X5S.

X5S:X5S is an add-on developed to work with fiddler. It users fiddler's packer logging technology and tries to find out which request may be the victim of cross site scripting by adding a Preamble in each request. But you need to have a proper understanding of Cross Site Scripting and encoding issues. It means everything related to Cross Site Scripting will be done manually.

Basically, X5S detects the places where a safe encoding was not applied for user inputs. Sometimes, Unicode characters transformation might bypass the security filters, so it also tries to check for that.

It sees the request and responses of URLs and then tries to inject XSS payloads to verify whether XSS is there or not. Now it's up to your talent. If you know how to manage running code in the place, you will find XSS easy.

One more thing I want to say about this tool is that you must know is that the tool basically focuses on reflected cross site scripting issues. It cannot detect DOM based XSS vulnerabilities. It will also not be able to verify stored XSS because the data will not be there in the request and responses parameters. You need to do extra efforts for other two kinds of XSS vulnerabilities.

If you want to use X5S to start hunting for XSS in a web application, download it from the link below and install it in your system. Be sure to install fiddler before installation of X5S.

Note: This tool uses request and response headers and then injects preambles in the parameter,so it supports both Get and Post parameters and injects preambles to test whether the application is vulnerable or not.

Download X5S

After installation, start Fiddler and you will see a new tab "X5S" in it. See the snapshot below:

Picture 2: X5s Tab in Fiddler

Here you will see X5S tab added in the Fiddler. If you are looking at the watcher tab and are not able to see in your fiddler, do not worry about that. Watcher is another add-on for fiddler that is used for cross site scripting testing. We are only interested in X5Sat the moment, so that's what we'll concentrate on.

Configuration

Before we start hunting for XSS vulnerabilities, we need to configure X5S properly. First of all go to X5S tab in fiddler and select the enable check box at the top. Now type XSS in Preamble text box. You can type any word, but be sure not to add any common word. This will be used by X5S to inject in each parameter of requests. Now select the check box saying Enable Domain Name Targeting and add the domains. Here add all those domains on which you want to test for XSS. It's up to you, as you can also add more than one domain.

Do not forget to select boxes "Requests" and "Responses", and in the Auto Injection Options, check all four select boxes.

[caption id="" align="alignnone" width="640"] Click on image to see a larger view.[/caption]

Picture 3: Configurations of X5s

Now move to test case configuration…

Test Case Configuration

In the fiddler tab, you see three tabs. Click on the second one labeled "Test Case Configuration"

In this tab we will find test cases for X5S that it will send as character probes. There are three types of test cases in this tool:

Transformable Test case: In this case, the probe character might appear in uppercase, lowercase, normalize otherwise transformed into other characters.

Traditional Test Case: In this test case, characters are used with XSS injections. These injections includes ", ', <, and >. I hope you know that these are the main characters that can cause XSS in a website if not properly filtered.

Qverlong UTF-8 Test Case: This is the last test case. In this it injects non-shortest UTF-8 encodings or traditional test cases. For example ASCII < will be denoted as 0x3C in UTF-8.

Select more or more from each category to start the testing. You can select as many as you want or all at a time. After this, we are ready to start XSS attack and hunting where we can inject scripts.

Picture 4: Test Case Configurations of X5S

To show the results, I am adding a domain that is vulnerable to XSS. But I will hide the domain name for the security of that website.

Now start surfing the website page by page and test all the forms. And keep on looking on results tab. If you found some search results, the website may be vulnerable to XSS attack. Now click on a result to show the detailed description in the text area below.

Picture 5: XSS Results in X5S fiddler

After selecting the result, it will show a description in the lower part. It will show how a preamble has been found on the page along with XSS characters. Look at the detail and try to analyze them. See the red colored texts in the description? It shows the preamble's occurrence on the page.

The next thing is finding the URL where this suspected vulnerability was found. See the left side of the Fiddler. It has logs for accessed URLs and we need to find out the URL request where this suspected vulnerability was found. Look at the log and try to find the request highlighted with gray color.

See the snapshot below. The URL is not visible to hide the website identity for security reasons.

Picture 6: URL request that have the suspected Occurrences of preamble

You can easily see that the URL inside the red box is highlighted with light grey color. Right click on the log found and then take mouse over the copy. Here select Just URL to copy the request URL.

Picture 7: Copy Request URL

Now Open the browser and paste the URL in it. Replace the preamble character with your XSS payloads in the URL parameters.

You can use following XSS payloads in place of the preamble to test for XSS

• <script>alert(1)</script> or <script>alert(1)</script> in case alert is being filtered
• "><script>alert(1)</script> or "><script>alert(1)</script>
• </style><script>alert(1)</script>
• ")</script><script>alert(1)</script>
• "><img src="a" onerror="prompt">

There are many XSS payloads which you can use in this situation. If while applying all these payloads, you got a Javascript alertbox saying 1, it was successful. Because we inserted Alert(1) in our payloads, it means the website is executing our scripts. So Cross Site Scripting is allowed at this site.

Picture 8: XSS Vulnerability found with Fiddler and X5S

Now try to see whether it shows cookies in the alert box or not. For this, change the payload and use alert (document.cookie) in place of alert(1) .

If the website shows the cookies in the alert box, it is seriously vulnerable and attacker can use this vulnerability to hijack sessions of the users in order to hijack their accounts on this website. It can harm users and the website alike.

This was the simplest demonstration how X5S can be used to find reflected XSS vulnerabilities on a website. It shows how important tool X5S is for penetration testers.

Why Penetration Testers Don't Use This Tool

There are many penetration testers who will never recommend this tool. The only reason is that we have so many other web scanners that come with all in one scanning technology. These scanners can crawl each and every URL of the website and then list all kind of vulnerabilities they found. Most of those scanners are good and work very well. This tool can detect only a specific kind of XSS called reflected.

It also takes too much time because we need to go to each URL manually. There may be possibility that we forgot a XSS vulnerable page to visit. In this case, it will not be able to test that page. Thus, after wasting lots of time, there may be a vulnerability that wasn't found due to software limitations.

Still, you can find many penetration testers who use this tool regularly. Everything depends on the choice of the tester. I recommend you give this tool a try. In the case that it works well for you, you can keep using the tool and find XSS in web applications. As beginners, you can try this tool to improve the knowledge of XSS payloads. Sometimes it may take hours to exploit the suspected place and inject the vulnerability.

Conclusion:

X5S is a nice add-on for Fiddler that can be used as a penetration testing tool to find XSS vulnerabilities. Use this tool only if you understand what Cross Site Scripting is and how many ways exist to inject external client side JavaScript code. If you are not good in manual XSS testing, this tool is no more than a waste of time for you. But for expert XSS tester, this tool may be the fastest way of finding XSS in the web application. As we have seen in the last example, it finds all the possible suspected hotspots where XSS may exist. You only need to test these hotspots and verify where it can execute external script or not. If you can inject, you were successful. Otherwise keep trying until you are done with all your XSS payloads. Only an experienced penetration tester can confirm that a suspected website is not vulnerable to a cross sire scripting attack because only he can understand the behavior of application's output and injected payloads.

As we know, this tool needs good expertise before using. It also takes too much time and we need to open every single URL and use all forms to check whether XSS vulnerability exists or not, and it can be a time consuming process. However, in the generation of automatic vulnerability scanners, this tool is used by only few researchers and penetration testers. It's a great place to start, though.