Just a reminder to everyone who is interested in WebAppSec and hasn’t done so already to try PHPIDS, the Intrusion Detection System. Here is the project’s description as listed on it’s the homepage says:

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. Based on a set of approved and heavily tested filter rules any attack is given a numerical impact rating which makes it easy to decide what kind of action should follow the hacking attempt. This could range from simple logging to sending out an emergency mail to the development team, displaying a warning message for the attacker or even ending the user’s session.

Installing PHPIDS is easy. Just download the latest version in your preferred format and then review the the FAQ for sample code on how to install it.

If you want more detailed installation instructions you can check out these links:

 

So when would I install it and what’s in it for me?

Now before you go and install PHPIDS in every application you have and deploy it in production, it is worth nothing that PHPIDS is just what it says it is… a basic, separate, intrusion detection system. And as such it suffers from the same problems that security experts criticize Web Application Firewalls for, namely that it doesn’t know (and in the case of PHPIDS won’t learn) ANYTHING about your application.

Put PHPIDS in front of an application for administering CMS HTML templates or a WYSIWYG editor and it will ‘complain’ every time a user uploads a new version of a template or edits some text, because all that HTML looks suspiciously like an XSS attack. Though I hardly noticed any slow down in the applications I’ve tested it with, it does add some overhead every time you have it execute a scan.

The strength of PHPIDS is pointing out potential flaws in your application and notifying you of suspicious user input. As such, if you have half an hour and would like to know more about the kinds of input your application gets, I would encourage everyone to try it out.

Install it in your app, make sure it only scans requests on the front facing side of your application (where you are hopefully not allowing HTML as input anyway), and leave it running for a while.
Perhaps, if you have a high traffic site, you only deploy it on one server or you limit the scans to some percentage of the requests.
Let it show you what it thinks is fishy input. Then, if it gives too many false positives, deactivate or de-install it.

At the very least you’ll learn more about how your users are (ab)using your application.