On the Script Tutorials blog today there's a good summary post reminding you of some of the common security issues that your web application can face, mostly due to improper validation and filtering.

Our new article focuses on security in web. Many beginners (and not only) web programmers sometimes can make mistakes when developing its web applications. Our article is intended to eliminate potential gaps in knowledge web developers. It is quite possible that you already know something, but I'll be incredibly happy if you learn anything new. Today we learn about most popular exploits (with samples).

Security issues that made their list include:

• SQL injections
• Cross-site scripting/Cross-site Request Forgeries
• Remote & local file inclusion
• Displaying errors on production
• Including .svn (or any version control meta) files in the production release

In a recent post to his blog Jason Stiles takes a look at some of the things you can do with PHP to help protect your site from XSS (cross-site scripting attacks) with some basic filtering.

Cross-Site Scripting (XSS) is a type of attack where a hacker attempts to inject client-side scripting into a webpage that others are able to view. The attack could be as simple as an annoying alert window or as sophisticated as stealing a logged in user's credentials (commonly saved in browser cookies). [...] Since these types of user input can immediately be displayed to other user's, the attack could be spread pretty quickly and even without your knowledge.

He provides a basic function to get you started filtering the input from your users - a "xss_protect" method that takes in the data, whether to strip HTML tags or not and an optional set of allowed tags if you do. He also asks for opinions and better methods in his comments:

No solution is going to be perfect, but at least now you have a head start! If you have ways of improving this function, let myself and everyone else know in the comments.

In a recent post to the Web Development Blog they talks a look at some methods you can use on your site to help reduce the amount of spam sent to email addresses by protecting them from scripts that might harvest them right from the page.

There are lots of spam bots checking the Internet for email addresses on regular websites, forums, blog and mailing lists. Once caught by some spam bot your mailbox is in need of a strong spam filter or sometimes it might be better to use a new e-mail address. In this article we show you different ways, how you're able to show your e-mail address to human visitors and hide it for spam bots.

They give four solutions, some a bit more practical than others - using an image instead of the text-only version of the address, hiding the @ symbol, hiding it with PHP (converting it to ASCII) and using Javascript to handle it similarly.

Juozas Kaziukenas has an example of how to keep you and your application's data safe from prying eyes by filtering input with the HTML_Purifier package.

It's really hard to decide what data is acceptable, especially when user has permission to insert HTML content through form. [...] However, problem can be solved, and quite easily. Almost a year ago I was reading some random blog when I find out about HTML Purifier. Basically, it's library which can filter and fix any HTML.

He gives an example - running a web scraping tool against a site with malformed HTML. By running it through the HTML_Purifier package first, the errors were corrected and the "more correct" HTML source could be parsed easily. The package also helps to protect from XSS attacks via a whole set of filters included by default.

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.

According to this new post on the PHP Security Blog, there's a new META tag the Suhosin extension includes in the output of a phpinfo page to help resolve some of the issues with Google (and buddies) storing the contents of the page, giving a potential attacker information they could exploit.

[The] extra META TAG to the HTML output of phpinfo() that forbids indexing and archiving by robots. For fairness reasons following the embedded links is still allowed to robots, because a lot of projects [...] to get at least a few backlinks for their work, that might result in a better search engine positioning.

The patch can be downloaded from their site.

PHPBuilder.com continues their look at preventing SQL injections in your PHP scripts with this new tutorial, the third part of the excerpts from the APress book Pro PHP Security.

They pick up where they left off last time with the creation of an abstraction layer for your application to act as a go-between and filter out possible bad data. They give examples of how to use it to secure a new application, use abstraction libraries like the PearDB functionality, and how to test your application's protection.

When it comes to protecting your code, you definitely want to find the right product for your needs. Finding the information on all of the encoders out there can be a task in itself, though. Fortunately, EncoderCompare.com has been created to give you a quick and easy reference.

Whilst we would always recommend the use of the ionCube Encoder product to protect your PHP source code when distributing your product to customers and users, there are several other products available to choose from.

To help with this, we have launched a comparison website which lists the available encoders and compares their features. The feature set is standardised so that it is possible to compare like for like in a clear manner.

Currently, there's fifteen encoders listed with all of their stats - protection types, restrictions available, what OSes it has loaders for, the availability of licensing, and the pricing. There's links to get more specific information on each as well.

In the ongoing quest of the guys over on the Hardened-PHP project to help protect PHP installs from the evils of the internet, there's a new project in development that could help make even more PHP installations more secure - Suhosin.

Suhosin is an advanced protection system for PHP installations. It was designed to protect servers and users from known and unknown flaws in PHP applications and the PHP core. Suhosin comes in two independent parts, that can be used separately or in combination.

The first part is a small patch against the PHP core, that implements a few low-level protections against bufferoverflows or format string vulnerabilities and the second part is a powerful PHP extension that implements all the other protections.

Unlike our Hardening-Patch Suhosin is binary compatible to normal PHP installation, which means it is compatible to 3rd party binary extension like ZendOptimizer.

There's already some information on the project posted on its homepage, but since it's still a beta preview of the code, the feature list and documentation isn't complete. If you'd like to check out this project in its early stages and see what it's all about, a great place to start is the current information including links to the downloads and how to get it set up on your install.

Markus Wolff takes a look at a part of the setup surrounding the Zend Framework in this blog post today - the Framework's CLA.

Contributors to the Zend Framework must first sign a Contributor License Agreement (CLA) before they're allowed to commit anything. This is claimed to make the Zend Framework "IP clean", so big corporations have no problem adopting it.

I've never believed in this proclaimed need of being "IP clean". Maybe that's because stealing someone's proprietary code never came to mind - am I just to good a person? However, in a world where in certain strange countries (I won't drop any names here) you can actually patent software - or worse, ideas - it is increasingly difficult to write a single line of code that you can be sure of not violating anyone else's so-called intellectual property.

He quotes from the CLA's FAQ on the Framework site about the protection this CLA offers to both the Framework and to the developers that contribute to it.

His rebuttal is one of "how can this be enforced?", which, of course, he realizes is just not possible. He casts a "marketing first" light on the CLA, suggesting that it's just a way to help sell it to corporations.