Security In, Security Out

Chris Shiflett has an interesting post on his blog wherein he declares that all PHP security vulnerabilities come from either a lack of flitering input or escaping output. In fact, he’s betting $100 that the next 4 of 5 vulnerabilities that get reported by PHP|Arch will confirm his proclamation.

My question is: what other kind of security vulnerability exists besides one that can be exploited by input either directly or as that input later becomes output to another application (like MySQL)? Define filtering broadly enough, and there’s really no way to loose.

But seriously….

What this really points out once again is that web applications written in PHP do not really need to focus on much more than absolutely everything that a malicious attacker could throw at you through GET, POST or COOKIES (unless they have access to your server ENVIRONMENT … *shudder*). Once again this means that if register_globals is turned off, these variables can only make their way in neatly packaged into corresponding $_GET, $_POST, and $_COOKIE arrays (as well as $_SESSION).

On the output side, you need a comprehensive understanding of the special characters or types of data that could cause unexpected behavior in whatever applications you will be passing data that contains any variant or subset of the data mentioned above. The controversial magic_quotes_gpc provides a somewhat cursory attempt at escaping characters that could choke MySQL from remote input. Relying on magic_quotes_gpc without a deeper understanding of what really needs to be escaped can be equally as dangerous as leaving register_globals turned on.

So, I guess we could say, “security is what you do between input and output.”