"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."

Your example includes the PHP interpreter. How exactly do you think code *HITS* the PHP interpreter? Your code is what's pulling it in. Similarly speaking if you could do a buffer overrun on Apache, it should not matter since Apache should be running as a weak useless account that can't do anything other than run Apache - so executing arbitrary code *as* that Apache account should not be able to do anything useful (IE, no delete perms, read-only perms to specific folders). Trust me, locking down a system isn't hard and when you get audited they're running machines that contain the known existing exploits and trying to achieve things. When I've been audited, system wise, they couldn't do shit even directly cabled into the back of the machine. Because locking down systems isn't that hard when it's what you know how to do. Regardless - the types of defects we're talking about with AT&T and with Phorum are not underlying overrun scenarios for Apache - they're bad code written by developers that is just lazy in nature which a qualified developer should not be writing.

"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. "

No one externally can break my ability to validate and translate input. I have to give them that ability by writing bad code. If it's my code that's rendering the page I can absolutely and unquestionably validate that input before writing it out to someone's browser.

"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. "

LOL what? You've got stevers agreeing with me here, so it's pretty chilly in hell but what are you trying to say here? Everything can be validated, including "raw bytes".


"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). "

These scenarios obviously don't apply to XSS but a secure system has configuration management, change control, multiple party consent to deployments, user acceptance testing/staged testing and user account management and auditing. The systems I built for the government by their mandate required RSA tokens, password rotation and dual party consent to deployments (coders did not have permission to deploy, a 3rd party handled deployments who had no rights to code). So yeah you can rule out the human element as well. You think the banking and military software systems run on a trust model?

It's not impossible to prevent intrusions. It's really not.



Edited 1 time(s). Last edit at 03/28/2014 05:47AM by Death_Claw.