Sometimes it’s good to be sad, especially if you’re looking to plug security holes brought on by using HyperText Preprocessor (PHP) on your website. Just ask PHP developers, who’ve found the depth of complaints on the phpsadness.com website to be instructional in coming up with potential solutions. PHP, an open source scripting language that runs on Linux servers and some Windows 2008 R2 servers to build dynamic Web pages, is installed on more than 20 million websites sites and a million Web servers, says Wikipedia. In other words, PHP security holes can have a wide-ranging effect. P is for Problem
PHP is looked down upon by many, because of past flaws in the language and, or implementation. Fuzzy Notepad goes into quite some detail about PHP's faults. It's a very long and detailed document and worth a read to give you a feel why some people don't like PHP. There's even a phpsadness.com website that goes into a fair bit of depth about some of the various faults of PHP, and by formally describing the various “sadnesses,” appears to be helping the PHP developers fix things. For instance, the e escape sequence for the Escape character was added to PHP 5.4 by a person who saw it on phpsadness. I've written a few reasonably complex websites in PHP and, in the back of my mind, I’ve always had a nagging suspicion that maybe my sites weren’t as secure as they ought to be. That's because I probably don't spend enough time learning about security best practices. It’s something I should do, given PHP hosting is generally cheaper than ASP.NET. Getting Better
Recent PHP releases have improved, like PHP 5.3. For example, the one way sha1 or md5 hash functions used to store encrypted passwords in databases are now considered weak. Since PHP 5.3, the php crypt() function has extra parameters to use a slower and more secure hash function. Also, part of the problem is not all programmers are familiar with PHP best practices and that can lead to security flaws on their sites. WordPress sites, for example, have had vulnerabilities that weren’t in the WordPress PHP code, but rather with one or two of the plugins that weren’t securely coded. I know, because a blog I had was hacked through one of them. The good news is that there are plenty of places that document best practices for PHP security. One is the PHP Security Consortium and the other by Stack Overflow has already delivered several really good answers. PHP haters be realistic. PHP security flaws will never go away entirely, but with nudges in the right direction, it can be gradually improved. Meanwhile, keep writing the code securely.