After months of stuffing our leisure with coding, discussing, testing, some imagery crafting and coordinating we are proud to announce the first official release of the PHPIDS - a project born in the holy halls of sla.ckers.org.

You might know what it's all about when you followed this thread:

http://sla.ckers.org/forum/read.php?12,8085

If not - here's the short version: The PHPIDS is an additional webapp security layer for any PHP application. Easy to install, maintain and based on a heavily tested filter set. It purpose is the recognition of XSS, SQLI, RFE, LFI and directory traversal attacks.

We built up a website including forum, TRAC, demo, docs etc. - maybe you'd like to make a visit ;)

Were false positives worked out after doing live test? I read something about testing it on site which gets 30,000 views (correct me if I recall wrong), wondering what issues arose and if they were serious enough to fix and if not what were they.

Are the regexs ready to be optimized so the package works faster? Or will you guys be waiting on doing that for time being until project becomes more mature. Just wondering since checked the regexes out and saw many can be heavily optimized to match faster.

http://phpids.heideri.ch/?test=;http://www.example.com/example.php
Says its a comment attack. Should be RFI or a redirection attempt. Pretty tricky to allow it since URLs are what make up a lot of content =o|

I umderstand that there plenty of vectors around, and it also raise my faith into whitelisting some more. Like catching anything that isn't [a-z]|[0-9] I worked a couple of time with it and it works pretty well. it also meant that every special chars is detected. It is a tough thing.

I agree with Ronald - it's not really possible to inject something destructive with that vector. but i think i will expand the rule or create a new rule. it's a nice impact-raiser. i guess it will be included in 0.3

Yes indeed, it's the programmers responsibility to check the data size a PHP structure is getting. It's one of the most forgotten issues, almost no one truncates data before sending it through htmlspecialchars() while we know it is prone to buffer overflows.

I think we could size down the full query string, and alerting only on insane long data sets. But, this is tricky cause it enables an attack also to spam one with false positives and bury and real attack.