Douglas Brown has a few helpful hints to help you write your PHP code defensively, protecting your code from malicious attackers.
The phenomenal growth of PHP applications has also led to a mushrooming of increased quantum of malicious activity. It thus becomes imperative that you write secure PHP code to protect your website. Here are some tips for the same. The three most vulnerable aspects of PHP that can become easily accessible to anyone are XSS (Cross Site Scripting), Global Variables and SQL code.
He details what each is and how you can protect your code against the problems they cause. Some example code is included to give you a better idea of the possible solution.
Jani Hartikainen has posted a few ideas on cross site request forgeries in a new blog entry, including some methods to help prevent it in your application.
CSRF, or Cross-Site Request Forgery, is a vulnerability very common in websites. [...] This can be dangerous, especially if your admin interface is compromised: There may be a button on the other site which goes to your admin interface and deletes the latest blogpost for example - and you wouldn't want that!
His method is a three-step process for protection - use POST, protect against cross-site scripting and use a CSRF key in the form to help prevent abuse. A simple script is included to show it working and is adapted to work in a controller plugin for the Zend Framework.
On the symfony blog Fabien Potencier encourages all symfony developers that the security of your application must be taken seriously and that, despite the built-in protection the framework offers, there still could be issues.
The symfony framework has always provided the tools needed by the developers to secure their applications. With the new form framework, we have added an automatic protection against CSRF. Speaking of the form framework, we have also added a lot of security features to protect you against all sort of injections.
He does include an example, though, of a situation where it's not just about protecting from cross-site scripting or attacks. It's about checking user input to ensure it's what it should be. They give the example of a user pushing an "is_admin" value into a form posting where there wasn't one and updating the right column to give them admin rights.
He mentions some work the Rails team has tried to do to prevent this sort of thing automatically, but Fabian points out what the symfony framework already does - prevent any injected fields other than what's in the forms from being submitted and included.
The IBM DeveloperWorks site has posted some advice that can help keep you, your application and your data safe from security-related attacks.
Security in a PHP application includes remote and local security concerns. Discover the habits PHP developers should get into to implement Web applications that have both characteristics.
Reform is a tool that does exactly this. Reform allows you to escape your data for a javascript, xml, html or vbscript (yes it still exists) context. It provides libraries for Java, .NET, PHP, Perl, Python, Javascript and ASP. Pretty cool!
The utility is simply included into the application an called via the static methods it adds. His example shows the escaping of some output text in a Javascript string to correctly prevent it from falling into an evil XSS scheme.
The CodeIgniter framework has made a new release today, 1.6.3, containing updates to fix a few bugs and address some security concerns.
We are happy to release CodeIgniter version 1.6.3 today. Version 1.6.3 is primarily a maintenance release, with a variety of bug fixes and some refinement to existing features (with a few new ones tossed in for good measure). Details of course can be found in the Change Log.
The release also fixes a potential cross-site scripting issue that, while it hasn't been reported as used yet, could still have some bad consequences if found and abused. You can grab this latest version from the CodeIgniter downloads page.
Stefan Esser has posted about the release of the latest version of the Suhosin security patch for PHP - version 0.9.21.
It has been a very long time since the last Suhosin extension has been released, but today this has changed with the release of Suhosin 0.9.21. Among the changes are two new features that will protect applications that put to much trust into the SERVER variables from several XSS (and SQL injection) attacks. These features are suhosin.server.strip and suhosin.server.encode.
He details these two features and gives examples of what they protect from. You can find out more about the Suhosin patch on its website.
Gareth Heyes has a quick new post to his blog today about the use of htmlentities and the false assumptions some developers have about it:
When someone uses htmlentities I've seen it time and time again that they expect that it filters variables from all XSS. This is wrong of course because the function requires a second parameter ENT_QUOTES which correctly replaces quote characters. Some developers aren't even aware that quotes can lead to XSS injection.
He reminds developers of the second parameter - the ENT_QUOTES parameter that correctly replaces quotes. Other people have mentions things in the comments as well like another optional parameter to force an encoding type and opinions about the function's use.
Chris Shiflettpoints out an unexpected SQL injection possibility as presented by Alexander Andonov for PHP (involving mysql_real_escape_string).
The focus of the article is stressing the importance of filtering input and escaping output, as neither is a substitute for the other, but he does so very clearly with specific examples [...] A number of example exploits are supplied for each case, and he discusses which ones work, which ones don't, and why.
I tried out the Pixy XSS and SQLI Scanner (http://pixybox.seclab.tuwien.ac.at/pixy/index.php) on a few simple PEAR files. On the first, I got a java exception, on the second it was unable to resolve the simplest of includes (no ability to resolve include_path). In short, the thing is useless for anything written using PEAR. Fun!
The Pixy XSS and SQLI Scanner is made to find SQL and XSS injection issues in scripts. It runs as a Java application and scans PHP4 source code to try to find problems. For more information on the scanner or to try it out for yourself, check out the project's homepage for documentation and downloads.
