Originally posted here by Irongeek
Understand your point, but this tutorial does not have to do with input validation. In this case it assumes the attacker already has the ability to put scripts on the target box. A better title may have been “Shoveling a Shell using PHP configured insecurely”. The "add prevention and mitigation" part is there. I mention editing php.ini and adding:

disable_functions=system,exec,passthru,shell_exec

to it, as well as refering them to a site with more information. Thanks for your feed back.
Yeah, I get what you mean. However my point is that I do consider this an input validation error since the first rule to input validation is "never execute unvalidated user input"...
The thing is, these functions by themselves aren't vulnerabilities, what makes them so is the fact that you pass it unvalidated user data/commands... You could very safely and legitimately make use of these functions to execute constant command strings which implies that it's not really php or it's configuration's fault but rather poorly written code that's at fault.

In this case it assumes the attacker already has the ability to put scripts on the target box
But then again, if the attacker already has the ability to upload scripts, your already in at least *some* trouble and it's the vulnerability that has allowed the attacker to upload content that is at fault...

Even then, further exploitation of the "upload" vulnerability would be mitigated if the http daemon runs as an unprivileged user (not root!), preferably in a chroot, and that file/directories write accessible by the httpd user *never* be so and executable at the same time...

Again, just restating my point, it's not the configuration that's the vulnerability here, it's the script... Let's put it this way: if I were able to upload scripts, you might just as well upload a cgi if php were "securly" configured not to exec...


Ammo