Two weeks ago, the SANS Institute has released its annual Top 20 Internet Security Attack Targets list. Of course you can debate how such a Top list came together and what the real value behind that is, but there are two specific points in this year's list that I found quite interesting.
First of all, there is a new entry: Users (H2). This shows that phishing, social engineering and related attacks are getting more and more prevalent. User education is therefore more important than ever.
Second, PHP is specifically mentioned a couple of times (one wonders why). In entry C2 of the SANS Top 20 (Web Applications), the institute gives some very specific advice:
From the PHP system administration and hosting perspective:
Always test and deploy patches and new versions of PHP as they are released
Frequent web scanning is recommended in environments where a large number of PHP applications are in use
Consider using the following PHP configuration:
register_globals (should be off, will break insecure apps)
allow_url_fopen (should be off, will break apps that rely on this feature, but protect against a very active exploit vector)
magic_quotes_gpc (should be off, will break older insecure apps)
open_basedir (should be enabled and correctly configured)
Consider using least privilege execution features like PHPsuexec or suPHP
Consider using Suhosin to control the execution environment of PHP scripts
Use Intrusion Prevention/Detection Systems to block/alert on malicious HTTP requests. Consider using Apache's mod_security to block known PHP attacks
As a last resort, consider banning applications which have a track record of active exploitation, and slow response times to fix known security issues.
From the developer perspective:
If you use PHP, migrate your application to PHP 5.2 as a matter of urgency.
To avoid the coding issues above:
Develop with the latest PHP release and a hardened configuration (see above)
Validate all input appropriately
Encode all output using htmlentities() or a similar mechanism to avoid XSS attacks
Migrate your data layer to PDO - do not use the old style mysql_*() functions as they are known faulty
Do not use user-supplied input with file functions to avoid remote file inclusion attacks
You could argue whether the PDO migration is superior to using, say, prepared statements (and why no other databases are mentioned). You could also argue why there is such an emphasis on PHP and that all advice is somehow well-known. But fact of the matter is, there are still so many PHP installations and PHP developers that do not follow these guidelines, as for instance Damien's survey shows. In my opinion, there is only one possible solution: Continue to talk with developers, continue to talk with hosting providers.
"Migrate your data layer to PDO - do not use the old style mysql_*() functions as they are known faulty"
Wha? I certainly hope that can back that claim, since to me it reads like BS.
Another important point that should've been mentioned that that often doing htmlentities($value); is not enough. This is the case because by default the function does not encode ' (single quotes), which are often used to enclose attributes. Which means that in instances where user input is printed inside an attribute enclosed within ', basic htmlentities() or htmlspecialchars() won't protect you. You need to call the functions with the ENT_QUOTES parameter that will ensure that ' will get converted to an appropriate HTML entity.
Of course you are right, I had sent a mail before, but no reply yet. Maybe they refer to mysql_escape_string() in their claims, or to the ability to change the charset? But it sounded very strange to me, too.
About escaping quotes: That's correct as well, but I see that as a detail. The mysql_* claims are more severe IMO.