Some technical details on how XSSDetect does Dataflow Analysis

Hi, my name is Hassan Khan. I work for the ACE Engineering Team, which is a part of the ACE (Application Consulting & Engineering) Team. We develop tools and solutions to help secure Microsoft Line of Business applications, websites and also work with Microsoft’s enterprise customers. ACE Engineering is also responsible for developing and delivering security courses and workshops that were originally targeted at IT application teams at Microsoft and which we also now deliver externally. The XSSDetect tool, the Threat modeling and Analysis Tool and the Anti-XSS Library are some of the tools developed by ACE Engineering which have been made available for free on the Internet. As one of the developers of XSSDetect, I wanted to share some of the technical details of this tool in this blog entry.

There are two types of web application vulnerability scanners: dynamic and static. Dynamic analysis tools are also called penetration testing tools. You point such a tool at a live application; the tool begins crawling the web pages in the application and throws test strings at each of them. The effectiveness of a penetration testing tool is therefore dependent on its ability to go through all the use cases in the application. Most tools in the market, if not all, are not very good at it. Static analysis tools on the other hand scan the application source code or binaries to detect programming errors. Consequently, they offer 100% coverage and are able to identify many more vulnerabilities than penetration testing tools. XSSDetect is a static analysis tool.

The reason there are so few static analysis tools available is that they are complex and hard to implement. XSSDetect analyzes .NET Intermediate Language (IL) read directly from the compiled binaries. It takes apart all assemblies, modules, classes and methods down to each instruction. It then identifies statements where untrusted user data enters the application and where dangerous methods are called. These form the two sets of statements (sources and sinks) between which XSSDetect then finds dataflow paths. This is the same algorithm that is employed when an application is code reviewed manually by an experienced security analyst.

Even though XSSDetect comes with hardcoded sources and sinks that help identify only XSS vulnerabilities, this approach can be used to identify any vulnerability that can be expressed in terms of sources, sinks and the dataflow between them. These include SQL, LDAP, XPATH, and XML data Injection vulnerabilities. Once you have dataflow analysis capabilities, it can indeed be very powerful.

The example below shows data is traced from Request.Querystring to Response.Write to establish the fact that a XSS vulnerability exists in the application. It is a simple example here data is only assigned to a variable before being echoed. In reality, before user input is passed to dangerous functions, it can be passed around in different assemblies, methods and assigned to object fields. It can also be stored in a database before being used! All these challenges had to be overcome to make this tool more accurate. Additionally, XSSDetect had to identify encoding and sanitizing functions in dataflow paths to reduce the number of false positives.

I will continue to share more details on XSSDetect in the future. For now, feel free to share with us your experience of using this tool. If you come across any vulnerable code fragments which XSSDetect fails to detect, please let us know and we will try to improve the accuracy of this tool. You can contact the ACE team by going to the ACE Team blog and clicking on 'Email'.

To download the tool and see a screenshot, check out the ACE Team blog here:

https://blogs.msdn.com/ace_team/archive/2007/10/22/xssdetect-public-beta-now-available.aspx