I’ve had some strong industry people look at AntiSamy including Jeremiah Grossman, Tom Stracener and others, and we haven’t had any XSS discovered yet. I sincerely hope that’s because it’s secure, but of course I’m not claiming it’s 100% reliable.

If you want to help us improve the policy file, take a crack at the test page I setup for anyone to access:
http://i8jesus.com:9080/AntiSamyDemoWebApp/test.jsp

Of recent note is Gareth Heyes’ Hackvertor XSS tool (I consider it a cross between .mario’s PHP Charset Encoder and the FishNet Security HTMangLe tool), the packer tool made available by Dean Edwards (I found out about this in the Web Application Hacker’s Handbook), and the Anti-Samy project at OWASP. I also just noticed Gareth Heyes has a new project, a JS/HTML Tag Inspector, which just gave me an idea on how to improve the WASC Script Mapping project.

One of my best resources for finding XSS has been the ASP.NET Content Encoding reference Excel spreadsheet that comes with the companion content from the Microsoft Press book, Hunting Security Bugs. If you have WAHH available, you can also check pages 580-581 for insight into using source code to find XSS vulnerabilities. Of special interest is to note that by knowing the framework and having the source code can be extremely useful for finding XSS, some of which may be nearly impossible to find through manual/automated black-box testing.

I’ve noticed a growing trend that people tend to think less of manual code review or automated source code security scanners, such as the recent GrumpySecurityGuy article on Source Code Scanning is Dead that you pointed me to. People also think that both source code and black-box scanners find “low hanging fruit”, especially XSS. I’ve met people who still feel that XSS is a medium or low rated vulnerability, to be included in reports “when nothing else can be found”. XSS isn’t taken seriously yet, and it’s considered to be “dealt-with” by using a secure framework. Most people would classify a framework “secure” just because it uses something like the Java Commons Validator. All of this is the farthest thing from the truth.

XSS is a highly critical issue. One only needs to look at AttackAPI or BeEF to realize the seriousness of this issue, and worse compare it to the number of active websites that have an XSS vulnerability. What’s funny is that after reading WAHH, I have a much lower opinion of DOM-based XSS, and an even higher opinion of reflected-XSS (although stored-XSS remains the nastiest vector of all of them). I also feel that no framework (not even HDIV) is going to prevent XSS throughout the entire application. Sure, improper validation can be the “root-cause” of SQLi and XSS - but these problems can’t be fixed by WAF’s or secure frameworks alone. They need to be fixed in the source, by using parameterized queries for all SQL, and proper-use of a validator on every application input along with proper validation/encoding on every application output (to combat all XSS). Then this needs to be verified with manual code review, regardless of the pen-testing involved.. In cases like MySpace where user-submitted HTML is allowed - there are projects like AntiSamy available, but these are not yet a panacea. Samy himself said that he already had ideas about how to beat AntiSamy, and I’m sure others are already charging their lasers.

The form ate up the markup…

Greetings,
.mario