Emmanuel Noobadmin wrote: > On 8/24/10, Keith Roberts <keith at karsites.net> wrote: >> So bolting down PHP really tight should address these hacks? > > As others have mentioned, this is trying to take advantage of a poorly > written PHP script that doesn't sanitize/check the input before using. > However, you could possibly lock down PHP further to reduce the > possibility of such apps working by using the disabled_function > setting to disable the riskier functions which allow > shell/command/file operations. Of course depending on how aggressive > you are, it could lead to scripts breaking. The best way to attack this problem is to take a close look at the known issues and make sure your code doesn't expose any of them. Start by reading the OWASP[1] web site. Their annual Top Ten[2] list of vulnerabilities is a good place to start. They also have sample code snippets in a variety of languages to sanitize and validate input. We utilize both their recommendations and code in a number of our sites. It gives us a good start toward PCI compliance. Another excellent resource is the "SANS-CWE Top 25 Most Dangerous Programming Errors"[3]. This applies to all applications that have network access, not just web pages. The press release[4] explains what the list contains. Bob McConnell N2SPP [1] <http://www.owasp.org/index.php/Main_Page> [2] <http://www.owasp.org/index.php/OWASP_Top_Ten_Project> [3] <http://www.sans.org/top25-software-errors/> [4] <http://www.sans.org/top25-software-errors/press-release.php>