In January 2005 I was having dinner with a computational linguist friend at a Red Lobster. While talking about provably-secure software, I ranted that with software as bad as it is today almost anything would be an improvement. "I mean," I said between bites of crab, "the right thing to do with input validation is so obvious, and nobody's doing it. You could stop most SQL injection just by moving to pushdown automata—why aren't people doing this?"

Meredith thought about it for a moment and said she hadn't thought of that, and hadn't heard of it before. She suggested there might be a paper in there somewhere, and I brushed it off. "No, no," I said, "for that I'd need to pick some hapless computational linguist's brain, and..."

I went on for another few sentences before I realized I was talking to a computational linguist.

We finished Draft 11 of Guns and Butter: Towards Formal Axioms of Input Validation on February 15. After circulating this within the department, our feedback was strongly positive. Our only problem was that if it got published in an academic journal, nobody in industry would ever read it. This led us to creating a presentation aimed at an industry audience, without theoretical computer science backgrounds. If you know SQL and you aren't scared by regular expressions, listen up.

Two injection flaws, XSS and SQL Injection, are the low-hanging fruit of the web application orchard. A day or two reviewing vulnerability feeds grimly suggests that developers are still just realizing what this class of attack means, and that the attackers are, as usual, two steps ahead.

By and large, we view these weaknesses as "input validation errors." That kind of language has a distinguished academic history dating back as far as the early Nineties -- perhaps even earlier, though our records of those ancient times are fragmentary. I'd happily blather about the merits of those vulnerability taxonomies for hours, but that won't cross the gulf between the academic and the practical.

So, let's unlearn what we have learned, at least briefly. We'll be able to avoid reinventing the input validation wheel, particularly that unending stream of broken or incomplete s/// perl-style substitution regexes. (I still see industry experts going so far as to label this a "best practice".) If thinking about "input validation" hasn't helped the typical developer, perhaps overtly ignoring it will.

I'll give a quick illustration of XSS and SQL Injection attacks portrayed as input validation flaws, and their proposed remediation, drawing from thoroughly unsurprising public mailing lists. I'll then hypnotize the audience, exploiting this suggestible state to implant general techniques and language-specific examples of injection flaw prevention.