So I took the opportunity during the OWASP San Jose conference to throw some of the ideas I’ve had bouncing around in my head at people. One of the things I was talking about was how strangely inefficient I thought the current XSS attack vector discovery paradigm was. What led me to this revelation was the realization that there was a paradigm at all. Small group of industry thought leaders + army of XSS fan boys/glory seekers + incomplete auditing style = fail. I’m not sure if that equation I just made up is mathematically sound, but it has more 1 reference to lolcats than other equations, and that’s in honor of the proud new dad on the block, Mr. Andrew van der Stock.

Every time we recognize another location where JavaScript can occur, or discover another encoding or fragmenting attack that, for some god awful reason or another, works in a major browser, we e-mail RSnake and he puts it in his cheat sheet, or we submit it to gnucitizen’s xssDB project. We’re doing the whole thing backwards, at least for open source browsers (Firefox, Konqueror – oh god, has anyone checked Lynx?) or open source browser engines (Safari’s WebKit). We can’t get a peek into the source code for some browsers (Opera, IE), but they should follow the same advice.

Start with the code.

Right now, we’re treating XSS attack vector discovery like it’s a blackbox penetration test. Open up the source and let’s work this thing from the other side! As someone with a good bit of experience not sucking ass at writing or reviewing code, I can tell you that we can provide a lot higher assurance if we review the code of the browsers in an organized way, rather than the current methods of discovery, which I will sum up here:

  • mistype an already known XSS vector and accidentally discover a new one
  • encode an existing XSS vector in a new way
  • use some kind of crazy insight/gut feeling to test a theory you pulled from the clear blue sky

Relying on these 3 techniques has gotten us this far – but do we really want to rely on these forever? Bonus follow up question: do you think all the XSS attacks have been discovered? If so, they’re always looking for new employees at the US Patent Office.

Man, I can see the flames now. Well, Mr. Smartypants, if it’s so easy, why don’t you do it? Reviewing a large application or an engine is not a job for one person. Incidentally, it’s also not a job for one team. With the amount of professional code reviewers out there, this could very easily be a community project (OWASP Spring of Code 2008, maybe?). A lot of eggs are in the browsers’ basket – and this is a way that we could help. I for one, will be looking at some browser code in my spare time and I’d encourage everyone else to do the same. Like my boss Dave Wichers said, there’s 5 billion web users, hundreds of thousands of companies writing web applications, and 6 browsers. Obviously, the most bang for your security buck will be with browser changes. That’s not to say the browsers can fix everything, because they can’t – but there’s no excuse for not fixing something that can be fixed there.

So, I gave this pitch to Jeff Williams and RSnake (do I really have to call you that?), and they both liked the idea. RSnake’s answer was funny, though. He said that he had indeed tried to do this a while back and that was how he discovered one 0-day vector. Unfortunately, though, he found the code to be such spaghetti that he couldn’t really make heads or tails of it. My response was, “Well, you should be able to look at the JavaScript engine and see where it gets invoked from”, to which he replied, “You’d think.” However, by his own admission, RSnake is the worst programmer in the world. So, grain of salt there.