New on the ITNewb.com site today there's a tutorial looking at making your forms a bit more "spam free" without resorting to CAPTCHA images.

Most anti-spam methods used by websites today are annoying at best. They use impossible-to-read captcha images, or they make users jump through some kind of hoop to get the email address instead of just clicking on it. This can mean lost sales and opportunities for you, because each hurdle turns away more users.

The trick uses some CSS and Javascript to hide a form field (display:none) and check on the submit to ensure that it's empty. The email address is the output of a Javascript document.write() as well, preventing those pulling the information off of your site without Javascript support (like some automated tools) to miss it completely.

As all of the WordPress users out there know, the "admin" section of the installations is one of the most important areas of your site. That being said, it should also be one of the most well protected parts. This new article from Smashing Magazine has ten tips that you can use to help protect you and your blog from prying eyes.

The administration area of a Web application is a favorite target of hackers and thus particularly well protected. The same goes for WordPress: when creating a blog, the system creates an administrative user with a perfectly secure password and blocks public access to the settings area with a log-in page. This is the cornerstone of its protection. Let's dig deeper!

Here's their ten tips:

• Rename and Upload the wordpress Folder
• Extend the file wp-config.php
• Move the wp-config.php file
• Protect the wp-config.php file
• Delete the admin User Account
• Choose strong passwords
• Protect the wp-admin Directory
• Suppress Error Feedback on the Log-In Page
• Restrict Erroneous Log-In Attempts
• Keep Software Up to Date

Douglas Brown has a few helpful hints to help you write your PHP code defensively, protecting your code from malicious attackers.

The phenomenal growth of PHP applications has also led to a mushrooming of increased quantum of malicious activity. It thus becomes imperative that you write secure PHP code to protect your website. Here are some tips for the same. The three most vulnerable aspects of PHP that can become easily accessible to anyone are XSS (Cross Site Scripting), Global Variables and SQL code.

He details what each is and how you can protect your code against the problems they cause. Some example code is included to give you a better idea of the possible solution.

On the PHPFreaks.com website there's a new article looking at one way to help protect your website from those evil doers out there looking to cause you and your data harm - PHP-IDS.

PHPIDS (PHP-Intrusion Detection System) is a simple to use, well structured, fast and state-of-the-art security layer for your PHP based web application. The IDS neither strips, sanitizes nor filters any malicious input, it simply recognizes when an attacker tries to break your site and reacts in exactly the way you want it to. [...] In a nutshell PHPIDS is an advanced intrusion detection system written with performance on a large scale in mind. The basic installation and configuration is pretty straight forward.

They (briefly) step you through the installation and configuration of the tool and provide a sample script to get the ball rolling - a file that can be auto_prepended to all scripts run on your Apache server to filter and log incoming requests.

Jani Hartikainen has posted a few ideas on cross site request forgeries in a new blog entry, including some methods to help prevent it in your application.

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.

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.