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

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.

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.

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.

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.

[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.

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.

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.

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.

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.