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.

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.

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.

The habits in their list are:

• Validate input
• Guard your file system
• Guard your database
• Guard your session
• Guard against XSS vulnerabilities
• Guard against invalid posts
• Protect against CSRF

Each comes with their own explanation and for some, code to help you spot the mistakes and correct them.

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.

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.

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.

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.

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.

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.

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.