Input validation is easy to say, in theory, but it means nothing in the real world.
It's also easy to say 'no vulnerabilities in any of my stuff' but this is pointless if your stuff sits on top
of other stuff that are exploitable. It's the weakest link that counts, not the strongest one.

**You can't start building castles on top of sand**

> If you look at the vulnerabilities for this software for instance, it's literally that they take parameters from a
> GET query string and render that HTML out directly to the person's page.

Yeah so you go on and filter all those strings, and somebody comes along with a 0day vulnerability in
the PHP interpreter itself that he's willing to burn on something like qhcf because he is
**sitting on lots of them** and blows the lids off your entire input validation theory.

Input means nothing by itself because it's raw bytes. You can only validate what you can account for
at the point where you do the validation, and there is no way that you can account for everything
that happens after you happily pass that data along down the chain.

You're also not taking into account security issues that stem directly from the human element,
such as system integration/configuration/logic errors. Where is your input validation there?
Some of the vulnerabilities that Stuxnet exploited, had nothing to do with input and everything to do
with programming logic errors (that could have been deliberate, that's another can of worms).

Look, the real issue for everyone in the know these days is not how to stop intrusions
(impossible) but how to detect them after they happen. Mandiant is pushing for 'open indicators
of compromise', the US cybersecurity groups are ramping up on sensor technology and
yet more research into data mining and further, most of the money flows into offense,
because the defense game is over and everyone knows it.



Edited 1 time(s). Last edit at 03/26/2014 11:52AM by zoskia.