Few quotes related to the PHP language are as pithy and resoundingly accurate as the phrase: "Eval is evil." The reasons are myriad: the eval() function basically gives whatever code is passed to it unlimited control of the parser, and this freedom makes eval() both a temptation for developers, who may need to dynamically control PHP at runtime, and a panacea for hackers who are ever-searching for more servers to add to their botnets. So, how does one make use of the extreme power available through runtime evaulation of PHP, without exposing one's server to near-certain rooting? Through a sandbox.

His tool - PHPSandbox, uses the PHP-Parser library to deconstruct the PHP code its given and look for issues. He gives an example of a call to mail and how it would catch the issue. He shows how to install it via Composer, how to configure it with whitelisted methods/functions. It also includes a way to overwrite function calls with a bit safer alternative.

I had a look at XSS Auditor for a bit of fun because Mario said it's getting harder to bypass. Hmmm I don't agree. I seem to remember the same flaws are present from the last time I checked it with a little variation. It is also a very limited XSS filter not supporting detection of script based attacks (very common).

He includes three of his own bypasses - using a "formaction" on the submit input in a form, using "target" to override the iframe external resource restriction and the injection of a specially placed anchor tag. Each of these comes with a proof-of-concept example and another is also included courtesy of Mario Heiderich.

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.