About

Why it was written

Finding XSS is boring and not very challenging. However, it can be very time consuming. We wanted a tool to automate as much of the process of finding XSS as we could. Our solution was tracy.

Background

There are many different ways to trigger XSS, especially considering the large number of frontend frameworks that have been made popular in the last few years. For example, some of the less traditional ways of exploiting XSS can be through:

• DOM clobbering¹
• DOM injection²
• Frontend template injection³
• Backend template injection⁴
• Open redirects⁵

These attack vectors are significantly different than traditional stored and reflected XSS cases and they require new tools for finding them effectively.

Many related tools only look for server response reflection, however this is not very helpful if all output encoding is performed by the frontend. In order to really gain knowledge about all the true sinks of the application, we need a tool that grants us "X-ray vision into the DOM"⁶.

tracy was written with the goal of eliminating XSS by assisting a penetration tester in identifying every source of input into an application and following that input to all of its sinks. These cases are documented and stored as references that can be used to identify the locations of potentially risky input.

1: http://www.thespanner.co.uk/2013/05/16/dom-clobbering/
2: https://www.owasp.org/index.php/DOM_Based_XSS
3: http://blog.portswigger.net/2016/01/xss-without-html-client-side-template.html
4: http://blog.portswigger.net/2015/08/server-side-template-injection.html
5: https://sites.google.com/site/bughunteruniversity/best-reports/openredirectsthatmatter
6: Michael Roberts

Sinks vs Sources

As tracy develops, these lists might grow to include other types of inputs and ouptuts. But for now, when we say sources, we are talking about:

• Form fields
• Query parameters
• Post body parameters
• Header values

and when we say sinks, we are talking about:

• Server responses
• DOM writes
• Instances of eval
• Instances of setTimeout
• Instances of setInterval

How it works

While browsing a web application, a user flags particular input they would like to be traced. The extension marks this input with a reference and documents any time this reference is seen in a server response, written to the DOM, or used in one of the other dangerous method mentioned above.

The extension makes use of the MutationObserver⁷ to monitor DOM writes. Additionally, the extension proxies⁸ a few functions that are considered dangerous and checks to see if these functions are executing arguments that contain one of the collected references.

7: https://developer.mozilla.org/en-US/docs/Web/API/MutationObserver
8: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy

What it is not

• It is not a web application scanner or automated tool. It requires human interaction and guidance about what the sources of input are.
• It is not an AI XSS finder.
• It is not a static analyzer.