Some backstory: When the Asprox mass SQL injection attack hit the web, HP teamed up with Microsoft and did a very cool thing. They donated a free, trimmed down version of their dynamic analysis tool called Scrawlr to the world. Scrawlr poked around your site, and if it detected SQL injection vulnerabilities, it let you know. Simple, useful, awesome.
When it came to fixing databases, people were at a loss in the beginning. Thanks to the blogotubes, database queries written by smart guys to detect and reverse the particular payload installed by the attack were spread pretty quickly.
Back to present day: Trying to find stored XSS in your database manually is insane. It just is. Even if you fix a stored XSS vulnerability with input validation and you’re convinced that it’s reliable, you could still have existing malicious data in your database that can still be used to harm your users. The fact is your database is probably just a huge abyss of data, and it’s not getting any brighter.
That’s why Aspect Security generously gave me work time to write a tool to automate that process. Even more generously, they donated the end result to OWASP (as they are wont to do). What resulted is a standalone GUI tool called Scrubbr, in hopefully obvious honor of and not theft from the Scrawlr folks.
Scrubbr allows you to get some visibility into your MySQL, MS SQL Server, or Oracle database when looking for XSS. It finds XSS vulnerabilities using AntiSamy as an engine. It can also actually fix any malicious data you encounter, also using AntiSamy. Fixing seems to work very well in MySQL and SQL Server but hasn’t been tested much in Oracle.
Here is a snippet from the OWASP page that talks about the use of AntiSamy in this context, as well as the “Fix” button:
Frankly, you’d have to be crazy to change production data with a tool you didn’t write yourself (and maybe even then). Trying to write a cross-platform database tool that can read and write is also a little crazy. The database technologies differ in so many stupid ways, and we mostly rely on JDBC to handle the interaction with the database. The “Fix” button is provided as-is, but of course we would like to hear about and fix your particular problem, and you can let us know about it at the issue tracker.
If you can tell Scrubbr how to access your database, it will search through every field capable of holding strings in the database for malicious code. If you want it to, it will search through every table, every row, and every column.
Scrubbr can detect input that doesn’t match up with an AntiSamy policy file. There is a subtle difference between “matching an AntiSamy policy” and being “detected as an attack.”
There are numerous tools out that *detect* XSS attacks in different contexts better than AntiSamy. The most prominent and peer-reviewed are NoScript (http://noscript.net) and PHPIDS (http://php-ids.org/category/PHPIDS/). However, detection is not strictly what AntiSamy does. AntiSamy checks if rich input that is passed in is allowed according to a policy file. Chances are that there is some input in your database that looks like rich input how we in the web world think about it, but actually isn’t.
With all of that being said, AntiSamy does an excellent job in most situations and will still detect the vast majority of stored XSS attacks, depending on the injection context.
So, hopefully in the future we can hook it up to a more appropriate engine like the PHPIDS ruleset. We will strive to make it produce less false positives in the future. However, regardless of the false positives I think we are a lot better off today than we were yesterday, so go download Scrubbr now!