Paid Advertising
web application security lab

PHPIDS Released

christ1an just announced that PHPIDS has been released. This has been in development for quite a while, but the intention is to react (more like an IPS than an IDS) to potential attacks. From the site:

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.

If you are running any custom PHP programs, I’d suggest taking this for a spin. As it is a first public release there will no doubt be some issues, but with the community’s help, hopefully this will turn into more of a ubiquitous tool to stop attackers from exploiting PHP applications. Please provide feedback about it’s use. I’m sure it will become a valuable resource. Nice work by .mario, crist1an and Lars.

14 Responses to “PHPIDS Released”

  1. beNi Says:

    Robert, people will never harden PHP ;-)

    Three tries, and the script killes itself (to much recoursion):
    “Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 67108872 bytes) in /home/phpids/demo/ids.php on line xxx”

    My hint: Although christ1an is German, they should at least try our own “special chars” , and =P

    regards, beni

  2. .mario Says:

    @beNi: Thanks - we already know this issue and fix is in prgress…

  3. .mario Says:

    Ok, we located the problem and plan to publish the 0.2.1 this evening (now+2hrs) including fresh filter rules and better UTF7 detection. thanks again for the input.


  4. Alex Says:

    Just some fun:


  5. Jib Says:

    It looks like the website is experiencing problems, as all I get is a page saying it’s scratching its feet, or something. I’m curious as to the benefit of this over a standard IPS solution. I couldn’t find a description. To me, from a 50 yard view, it seems redundant and adds additional load to a critical device (webserver).

    I’m not trying to discredit your work, but I think I must be missing something?

  6. Alex Says:

    I think, they have taken it off until the new release.
    If you want to take a look at it, go out and visit
    (don’t know the version).

    Explanation of the benefit over an IDS/IPS:

  7. .mario Says:

    Yes - unfortunately we had a database crash - I’ll call in when problems are solved…

  8. Stefan Esser Says:

    Well the good thing about all these HTTP aware IPS, IDS, WAF is that they created a “new” class of vulnerabilities in web applications/web servers.

    Nowadays you can completely stop people from using a particular web application by infecting their browsers with cookies that will trigger the IPS, IDS, WAF rules and deny the request.

    Infection ways are many: vulnerability in the app or in another app in the same domain, universal xss, browser cross domain vulns, browser plugin cross domain vulns, … And for example can still set cookies for * in Firefox. One cookie is enough to “DOS” all PHP servers in korea… I call that effective…

    I gave a talk about this problem at the cologne PHP user group on 1st June.

    PS: This problem is exactly the reason why Suhosin drops input variables that were detected as malicious instead of blocking the whole request.

    PS2: Servers using mod_snakeoil^H^H^Hsecurity can usually be dossed with a simple cookie like name=%00%xx%

  9. christ1an Says:

    Stefan: Good point however not applying to PHPIDS and therefore calling it a new class of vulnerability makes as much sense as calling Suhosin a vulnerability of that kind.

    From the very beginning the PHPIDS was never designed to block or sanitize anything by default. The only goal it tries to achieve is to detect possible attacks.

    But thanks for your advice, we’ll cover that part in the documentation so developers don’t fall into that trap.

  10. Alex Says:

    Addendum: You have to use Firefox 2.x and have JavaScript enabled for that link above to work.

  11. Stefan Esser Says:

    christ1an: If I see correctly you check _REQUEST in your example for CakePHP. _REQUEST contains cookies. And what is the application supposed todo with the information that it is attacked? It will most probably refuse to work with a nice error screen.

    Voila… DOS through the usage of PHPIDS.

    Btw I did not call PHPIDS a “new” vulnerability but DOS through Cookie Infection. A whole bunch of web applications are vulnerable to this. Especially all those using _REQUEST all over the place.

    The message is simple: when you scan cookies for attacks the only option you have is to remove those that attack you. Blocking completely is no option and letting them through is also no option. But even if you drop only those considered an attack PHPs feature to ignore whitespace in the beginning of a variable name is still breaking your neck (if you try to handle it from PHP userspace).

  12. christ1an Says:

    Yeah your statment about DOS through cookie infection is absolutely right and I also agree that many applications will be vulnerable to this.

    However I need to defend the PHPIDS on this matter. It is not the PHPIDS that makes the application vulnerable but the kind of reaction the developer implements.

    So consider the CakePHP a bad example that should be imrpoved the way you proposed to prevent DOS attacks.

  13. .mario Says:

    “However I need to defend the PHPIDS on this matter. It is not the PHPIDS that makes the application vulnerable but the kind of reaction the developer implements.”

    exactly - if you use the PHPIDS and implement a reaction like showing an error page (like we did in our still fucked up blog) you should pretty much know what you’re doing and when you do it. that’s the reason why you don’t find example logic that redirects or does worse in the examples.

    For learning sake you should use the PHPIDS in silent mode first - and log or mail what’s coming in - to give you an overview on what’s happening on your domain and where.


  14. .mario Says:


    We’re back - Trac and forum are still down but you can use page and downloads again. I guess by tomorrow the whole estate should be working again.

    Thanks for your support!