More Rude Awakening

Well, I don't have many good answers yet, but a few other things that work against us:

• Things like application firewalls (I have lots of problems with them, this is one) ultimately tell the developers that they don't have to write good code.
• When you do a search for Cross-site Scripting or XSS, you'll find a million examples of things like MySpace that allow you to do HTML. The fixes are always more input validation. For 90% of applications out there, output filtering is a more complete solution.
• The proposed fixes from the tools are generic, not specific to a developer's framework.
• The proposed fixes from the tools are often wrong because they're generic. (Case in point, SQL Injection is best fixed by business-rule input validation, and parameterized queries/prepared statements. The problem, however, is that those are platform specific, whereas saying to escape apostrophes isn't.)
• The solutions widely on the internet are also wrong or at best, incomplete.
• It's rare to find somebody who is both a security expert and an app expert. It's even more rare to find somebody who is both of those and is able to clearly translate our very technical jargon into terms that adequately describe what we find yet are still "accessible".
• The automated tools identify problems, but don't enforce solutions.
  

I've only managed to come up with a few ways for us to defend ourselves:

• One benefit that we can provide that the automated tools cannot is that those of us who stay in touch with development can more adequately help developers to find solutions that are specific to their implementation. This is probably our biggest benefit over the automated tools besides being able to find logic flaws and "the other 10%".
• In those occasions where we get to show of our skills, our exploit documentation can have really good shock-and-awe scenarios. Don't pop a message box with 'XSS' in it, show a multi-step process of an ordinary user logging into a hacker site with their credentials to your app. Show the attacker getting products for free. Do some Photoshop magic and put the victim company's name on the front page of the Wall Street Journal.
• Those of you who are really good, widely-respected, and are able to communicate clearly (you know who you are), be more vocal. When developers do a search for ([XC]SRF|Session Riding), they'll be more effective when they see the good solutions out there, which is something the automated tools simply can't provide (not that they truly find it yet, anyhow).
• Be sure to document the dangers of logic flaws. Emphasize those over the semantic flaws. The logic flaws are the human difference. Really document well those things that make the manual process great - the human intelligence required to discern a good privilege escalation/jumping attack, the dangers of showing too much information, the results of key exposure.

When sites get attacked, the attacks that work are going to be the ones methodically worked out by a person, not a tool. We need to be able to show that we're able to apply the same type of analysis as people as the bad guys do. Intuition is something the tools simply can't provide - we need to be able to sell that to our customers.