Evert Pot has pointed out a handy tool that can make escaping strings in and out of your application simpler - Reform.

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 Shiflett points 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.

Chris also uses the post to link to Paul Reinheimer's post about add_slashes versus mysql_escape_string and his own post on the same topic.

Greg Bever has a (very) quick post about his experiences with the Pixy XSS and SQLI Scanner running against PEAR files.

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.

Secunia.com has posted a PHP-related issue that users of the PHPChain application should look into:

r0t has discovered some vulnerabilities in PHPChain, which can be exploited by malicious people to conduct cross-site scripting attacks.

Input passed to the "catid" parameter in settings.php (when "action" is set to "edit") and cat.php is not properly sanitised before it is returned to the user. This can be exploited to execute arbitrary HTML and script code in a user's browser session in context of an affected site.

If a user is logged in and the exploit is in place, the attacker could gain access to the application and gain access to a user's information. The recommended fix is to correct the source code so that the information coming in is correctly sanitized.

TCExam users will definitely want to pay attention to this latest advisory posted by Secunia detailing a PHP code execution and cross-site scripting issue that's been found:

rgod has discovered two vulnerabilities in TCExam, which can be exploited by malicious people to conduct cross-site scripting attacks or to compromise a vulnerable system.

The two issues is related to two different inpus not being handled properly - the mishandling of the SessionUserLang cookie and the _SERVER[SCRIPT_NAME] value. Neither of these are being sanitized.

This issue effects users of the TCExam 4.x series but a new version, 4.1.000, has already been released and made available for download.

WordPress users listen up! Justin Silverton has pointed out a new update for your favorite blogging software to help keep things secure.

From the WordPress site:

These releases include fixes for several publicly known minor XSS issues, one major XML-RPC issue, and a proactive full sweep of the WordPress codebase to protect against future problems.

There's also a mention of the added security they've implemented to help protect from something like this previous issue happening again.

Download the files directly:

• for version 2.1.3
• for version 2.0.10

In an article from the Zend Developer Zone by Manuel Lemos, there's a look at how to avoid cross-site scripting security attacks on a site that allows users to input information via a HTML editor.

HTML editors are great. However, care must be taken to avoid security abuses. An application that uses HTML editors, expects that the submitted HTML content comes correctly formatted and well-formed. That happens when real users use real browsers to edit the content.

However, an attacker may create a program that pretends to be a real browser and submit specially crafted HTML with Javascript that may open security holes.

Manuel talks a bit about what cross-site scripting means in this context and a simple (Javascript) example of how a user could abuse it. His solution? Parse the incoming data (filter it!) and look for potentially harmful tag types. To do this, he recommends the PHP Input Filter class. There's even a simple example of how to use it included in the post.