Support/Comments for PHPIDS 0.6.1.1b-update

How to work with the impact?

The impact indicates the severity of the attack. The PHPIDS brings around 50 filter rules to detect attacks and each one of them has an impact – the more rules match on the incoming data, the more likely it’s an attack and the higher ranks the resulting impact.

The impact can be received by using the $result->getImpact() on the result object.

You can store the impact as session value, if you want to track an attackers activity for some time and wish to react later – when session impact has risen to 50 or 100. A usual very first attack impact is around 5 – 10 – sometimes 15 -20. A typical XSS probing monitored by session based impact usually results in an impact of 50 – 150. So it’s pretty easy to separate the false alerts from the real attacks using session based impact.
What can be done in case the impact is very high?

There are several ways to react on high (around 15) or very high (around 25-50) impact – first and easiest would be a hard redirect – the suspicious user could be redirected to a warning page which tells him that the application considered his input malicious and asks him to stop. Meanwhile all important parameters of the user can be logged and used for forensics. Another effective way would be to destroy the users session.

Basically the PHPIDS leaves the choice on what to do up to you. If you found a smart way of defending your application in case of very high impact feel free to let other users know via our forum.
What about performance issues?

The PHPIDS is being developed under constant profiling with xdebug and performance measurements to make sure that your application will not become noticeably slower. Only request parameters are checked whose values inhabits characters besides a-Z, 0-9, @ and _.

Furthermore modules like the HTML parser are only included and used in case there is input coming in with a key matching the ones given in the Config.ini / via $monitor->setHtml() for content with HTML allowed. So the performance hungry components normally won’t be loaded during about 95% of all requests.
How to get information about new releases?

Just subscribe to our newsfeed. By the way – the API is not going to change in the coming releases – if yes it will pointed out prominently in the news and the forum.

Question: it seems the plugin is triggered when a page is rendered, but is the dangerous data not already in the database at that moment?

Olaf