Here's a quick tutorial to get you familiar with x5s and how to use it. I'm assuming now that you have Fiddler and x5s installed
Open Fiddler, go to the x5s tab, click Enable
. Type in the Preamble
'pqz'. Check the box to Enable Domain Name Targetting
and add the domain 'nottrusted.com'. Be sure to enable the two check boxes for 'Applies to' requests
. Further down in the configuration options you'll find the 'Auto-Injection Options'. Be sure to enable all of them
. If you enable the 'Throttle request generation' you can play with the settings, but a delay period
of 1000 and a batch size
of 25 should be fine for most cases.
You're almost set up! Just on to the test case configuration after this. You can leave all the 'URI Encoding Options' disabled for now. Your screen should look similar to the one here:
Test Case Configuration
Now move to the 'Test Case Configuration' tab, where you'll find all of the test cases x5s will send as character probes. These are single-characters that x5s injects into the inputs of a Web-app. There's three main types:
We'll pick one or more from each category to get started. Check the box for the following four characters:
- U+FF1C FULLWIDTH LESS-THAN SIGN from the Transformable test type
- U+0130 LATIN CAPITAL LETTER I WITH DOT ABOVE from the Transformable test type
- U+0022 QUOTATION MARK from the Traditional test type
- U+003E GREATER-THAN SIGN > from the Overlong test type
We're all set and ready for testing! Now on to to the Results.
Interpreting the Results
Go to the 'Results' tab, it should be empty because we haven't hit the site to test anything yet. Now open your favorite browser. IE, Safari, and Chrome will all use Fiddler without any special configuration. Firefox has a Fiddler plugin you can use, or else you can set your proxy settings to point to Fiddler. Typically this is 127.0.0.1 port 8888. To find out, check Fiddler's options.
In your browser, navigate to http://nottrusted.com/x5s/
and follow the instructions on that page. There should be a link for you to click which will pass some values on the query string. x5s will see the value and start auto-injecting the test cases by resending the request once per input parameter for each test case. If you switch over to Fiddler and look at the x5s Results tab, click the shot hotspots
button and you'll see results similar to the following:
On the left hand side are the sessions (request/response pairs) that Fiddler captured and stored. On the right is the x5s Results window. Click on the first row, which should say 'Transformed' in the Transformation column, and 'ff1c' in the Code Point column. In the very first column of that same row, you can see the test canary and get a quick view into how it was rendered on the page. This shows you quickly that the U+FF1C FULLWIDTH LESS-THAN SIGN character probe was indeed transformed to a dangerous < character.
In the bottom half of the Results window, x5s shows you more of the context, the HTML source you control, and attempts to highlight the test canary for you to quickly recognize. We have a known work item
where the highlighting is slightly off from what it should be.
If you double-click this row you'll be taken to Fiddler's session inspector. This view shows you the HTTP request on the top and the response on the bottom. There are different views available as buttons to show you the request/response in the raw, in hex, in parsed form, XML, etc. At this point, you know that a character transformed and you can manually perform the next step to verify a working XSS attack by testing "><script>alert(1)</script>.
However, let's stay here for a minute and look at the next row.
In the context column, you can see your canary again, followed by the test probe ">", in all it should look something like 000epqz>
. Because the test case probe ">" was returned unencoded, it has the Transformation type of 'None'. Sigh, this is probably the confusing part, and something we're looking at changing. Think of it like this - you sent in a ">" and it was returned just as you sent, so there was no transformation and no encoding. Now that's a problem potentially! Right? :)
In short, the verification that you control the HTML would look like http://nottrusted.com/x5s/?input=";alert(1);//
That's it. Now a similar process will happen for forms, JSON, and other requests that your Web application sends. From here you're on your own.