In this new tutorial from PHPFreaks.com they talk about a subject that should be near and dear to every PHP developer's heart - application security.

The problem is that most people forget one of the most important aspects that one must consider when writing PHP applications. Many beginners forget the security aspect of PHP. Generally, your users are nice people, they will do as they are told and you will have no problem with these people whatsoever. However, some people are not quite as nice.

They've included some tips to help protect you and your application from these "not quite as nice" users hanging out on your site. They talk about:

• Error reporting
• SQL injections
• Cross-site scripting
• Outside file access
• Remote file inclusion
• Session security
• Cross-site request forgery
• Directory traversal

Each topic explains what it is, how it can be used against you and what you can do to help stop it on your site (including example code).

In this new post to his blog today, Lars Strojny looks to clear up some of the confusion that might be forming around the term "intrusion detection", more specifically, related to projects like PHP-IDS.

PHP-IDS is an intrusion detection tool on the application level. Application firewalls know about a certain protocol and its structure (e.g. HTTP) and inspect the protocol to detect attack patterns. Some of them are even capable of learning from usual request signatures and enforcing rules based on the learned data. There are various commercial products to achieve application firewalling. PHP-IDS does the same for free and sits directly on the webserver in the scope of the application.

He recommends it as a good supplement to the hardening you've already done for your server (you have hardened it, haven't you?) to help keep you and your data safe from prying eyes.

Vinu Thomas has posted about a PHP/GD CAPTCHA solution he's come across - Secureimage.

From the company's description:

Securimage is an open-source free PHP CAPTCHA script for generating complex images and CAPTCHA codes to protect forms from spam and abuse. It can be easily added into existing forms on your website to provide protection from spam bots. It can run on most any webserver as long as you have PHP installed, and GD support within PHP.

Features of the tool include simple addition and validation methods, the ability to make audible CAPTCHAs and True Type font support. You can download the software from the project's website.

Jonathan Snook has posted a helpful trick for CakePHP users out there looking to secure sections of their site away from "normal users" and keep it only in the hands of the admins.

I just wanted to document this for easy future reference but if you don't want to hook up a complex user adminstration with authorization components, you can simply specify that the admin path be password protected in either your .htaccess file or in your httpd.conf.

This method is actually one of the built-in methods Apache has for restricting access (http authentication) that he's placed on his "/admin" directory. Call htpasswd to create the password file and you're all set to go.

In a new post to his blog, Chris Hartjes, spurred on by an article in the latest edition of php|architect magazine (covering protecting your code), has shared a few opinions starting with a certain paragraph near the end.

To start, I will focus on the paragraph above. What I get out of that is that if only your source was closed and hidden from prying eyes, it would not have bugs in it. Which is, of course, total nonsense. Code has bugs because it's open and they feel safer? There are two kinds of bugs: application bugs (which is the code I would write) and system bugs (in this case, bugs that that appear from PHP itself). I'm sorry, but there is nothing I can do if there is a bug in PHP that causes my application to crash except to point this bug out to the people who have the ability to fix it.

He goes on to talk more about how protection like this (the article talks about using the IonCube Encoder) will not stop someone if they're really determine to get at the code underneath the encryption. His only suggestion is to make an application good enough that people wouldn't want to try to steal it as much and would rather pay for their version.

Encode your stuff if you want, but be aware that the minute you choose to do that you are telling your customers "I don't trust you" and I have a hard time understanding a business model that assumes people are going to want to steal the stuff you sell.

On the PHP 10.0 Blog, there's a new post today talking about variable tainting and what it might be like if PHP included it too.

Perl and Ruby have variable tainting. Maybe PHP should have it too?

Variable tainting is a bit of built-in functionality that provides a "safety net" of sorts to the contents of variables to help protect both the users and the script itself from potentially harmful content.

He talks about how Ruby and Perl handle the functionality and how, were PHP to work it in, which approach would fit better with PHP's current model:

If one wants to implement proper tainting or sandboxing, it probably should be based on more generic approach that would account for existence of functions unknown in design time.

In his laste blog post, Steve Hannah shares some of his "adventures with PHP compilers" that he's had in the process of finding something to help him protect his work.

I am in a situation where I need to protect some intellectual property in a PHP script. The recommended solution is to use a code obfuscator (or compiler) to encode the script. Currently the landscape leaves much to be desired in this area as far as PHP is concerned.

He talks about Zend Guard, Source Guardian and bcompiler. It's this last one he focuses on the most, noting that it's a dynamic PECL extension to be included into PHP and used, but it doesn't quite seem to work so easily. He finally manages to get something compiled, only to find it doesn't work when executed anymore.

Conclusion: bcompiler is not ready for primetime yet. Please someone correct me if I'm wrong on this point.

He had higher hopes for SourceGuardian, though, and thankfully, it seemed to pull through. His second post on the topic notes that it "worked flawlessly" when he encoded the file and just as easily when decoding and running the script as well. He highly recommends it to anyone looking to protect their PHP source code.

In his latest blog entry, Chris Shiflett looks at a debate that's been going for a while now - addslashes() versus mysql_real_escape_string().

Last month, I discussed Google's XSS Vulnerability and provided an example that demonstrates it. I was hoping to highlight why character encoding consistency is important, but apparently the addslashes() versus mysql_real_escape_string() debate continues. Demonstrating Google's XSS vulnerability was pretty easy. Demonstrating an SQL injection attack that is immune to addslashes() is a bit more involved, but still pretty straightforward.

The reminder of the post explains the difference, how how protects you when the other doesn't (addslashes), and a simple example of how something like that could be accomplished, including code...