From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
Developer(s) Mario Heiderich, Christian Matthies, Lars H. Strojny
Preview release
0.7[1] / August 26, 2011 (2011-08-26)
Written in PHP
Type Web application security
License LGPL

PHPIDS (PHP Intrusion Detection System) is an open-source intrusion detection system for PHP web apps. It was written by Mario Heiderich, Christian Matthies, Lars H. Strojny and several others in March 2007. It was then ported into other frameworks later on,[2][3][4][5][6] and distributed under the LGPL License.


The main goal is to give every PHP programmer the ability to log and monitor all php interactions which are sent from an external context (client-side) to an internal resource (any given php web application). A stated goal of the project is to reduce costs (both hard and soft) by reducing the effort needed to secure a given php module by adding detection as a discrete layer across the entire threat surface. It specifically does not aim to prevent malicious actions but instead to monitor and log every event, and in cases where a rule has been defined, take a predefined action.


PHPIDS detects Cross-site scripting (XSS), SQL injection, header injection, Directory traversal, Remote File Execution, Local File Inclusion, Denial of Service (DoS). It is simple to use and well structured. It provides impact of every attack by analyzing any chosen input variables as POST, GET, SESSION, COOKIE.

Forks to other Software

PHPIDS module adds a security layer for Drupal [7]
Mute Screamer - is a WordPress plugin based on PHPIDS [8]
PHPIDS Extension for MediaWiki developed [9]
ZIDS - PHPIDS module developed to add extra security to Zend Framework Applications [10]
px_phpids - an extension developed for Typo3 based on PHPIDS [11]
dotnetids - a similar project as PHPIDS to secure ASP.NET Applications written in [12]
PerlIDS - PHPIDS ported to Perl module[13]

ModSecurity is a web application layer firewall uses the PHPIDS default filter rules in their packages.[14]


PHPIDS tries to apply several regular expressions to detect "known bad." By doing so, it essentially takes a blacklist approach. Additionally, it attempts to detect unknown patterns by applying heuristics. As with any blacklist, it will fail in detecting currently unknown threats, thus requiring the administrator of any application to constantly update this library to stay current with new attack vectors. This weakness is not a result of the use of this module, but of an objective to minimize instances in which this application breaks the functionality of the webapp. Essentially, it is better to have users able to interact with your site than to catch every malicious actor on the first attempt every time.

Furthermore, using PHPIDS as the primary means of application security will lead uninformed developers into wrongly assuming their product is safe, when this is not the case. Any well-informed developer should be taking steps internally to secure their application's codebase, and any actors on the defense side should understand Defense in depth and use multiple solutions to secure their resources. PHPIDS is not intended to be a panacea, but it does provide logging abilities well beyond the built in functionality which would exist without (inbuilt tools are limited to logging GET requests). Additionally, the output of a PHPIDS check is not a binary value, but rather an integer value, allowing a probabilistic estimate of harm instead of a black & white binary value. This allows the developer to make informed decisions per-application instead of defining a hard-and-fast rule which may inadequately address the needs of a certain application. The downside is that obviously this is imperfect as the assigned values or the cutoffs for said values may not catch all attacks.

A better approach would be to apply secure programming tactics independent of any IDS system and create a secure application. Adding PHPIDS on top of that might enable the application to detect malicious users, possibly tagging them as being evil, and alert the administrator or log any attacks detected for later review. These steps have to be added by the application developers themselves, as PHPIDS does not offer such features.

Detecting possible attacks via regular expressions has a slight performance penalty on the application.[15]


  1. ^ "Archived copy". Archived from the original on 2012-03-20. Retrieved 2011-11-12.
  2. ^ "Zend Framework Intruder Detection System". Retrieved 2011-02-20.
  3. ^ "MediaWiki Extension". Retrieved 2011-02-20.
  4. ^ "TYPO3 Security / Intrusion Detection System". Retrieved 2011-02-20.
  5. ^ "Mute Screamer - PHPIDS for WordPress". Retrieved 2011-02-20.
  6. ^ "dotnetids - Intrusion detection system for .NET based on phpids". Retrieved 2011-02-20.
  7. ^ "PHPIDS module for drupal". Retrieved 2011-02-20.
  8. ^ "Mute Screamer - PHPIDS for WordPress". Retrieved 2011-02-20.
  9. ^ "MediaWiki Extension". Retrieved 2011-02-20.
  10. ^ "Zend Framework Intruder Detection System". Retrieved 2011-02-20.
  11. ^ "TYPO3 Security / Intrusion Detection System". Retrieved 2011-02-20.
  12. ^ "dotnetids - Intrusion detection system for .NET based on phpids". Retrieved 2011-02-20.
  13. ^ "CGI::IDS - PerlIDS - Perl Website Intrusion Detection System".
  14. ^ "ModSecurity Core Rule Set (CRS) PHPIDS Smoketest". Retrieved 2011-03-06.
  15. ^ "PHPIDS - Monitoring attack surface activity". Retrieved 2011-02-20.

External links

  • Official website
Retrieved from ""
This content was retrieved from Wikipedia :
This page is based on the copyrighted Wikipedia article "PHPIDS"; it is used under the Creative Commons Attribution-ShareAlike 3.0 Unported License (CC-BY-SA). You may redistribute it, verbatim or modified, providing that you comply with the terms of the CC-BY-SA