Generic SQL Injection

Unanswered Question
Aug 8th, 2008

Hi, regarding IDS signature 5930. This appears to be an old signature re-released with the recent asproxy vulnerabilities in mind. We have seen this fire with subsig 5 (asprox) and subsig 4 which detects " AND 1=1" in HTTP arguments. However when we look at the captures for subsig 4 alerts we are unable to find this argument in the capture anywhere (TAC currently raised).

Also, what is the best method of protecting against these vulnerablities - is it just a case of te developers ensuring that the code is not vulnerable? There is an MS test tool available to help with this

Does anybody have any similar thoughts on this and the best way to defned against this?


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
mhellman Fri, 08/08/2008 - 06:42

subsig 5 is probably legit (e.g. asprox, something trying to inject SQL). I'm quite surprised you've actually seen subsig 4 fire. I don't get why an attacker would use "AND 1=1" because it would evaluate to false. "OR 1=1" is the more classical example makes more sense because if it works it will evaluate to true. The regex is pretty basic though:


Therefore, it won't match unless it sees " and 1=1" or " and 1=2".

do you have just the contextual data, or do you have the trigger packet and/or log packets?

If you're inline, you could use a drop action. If promiscuous, you might be able to use TCP resets. The real fix is to use a "white list" approach to filter input in your web applications.

mhellman Fri, 08/08/2008 - 07:08

I'm also confused why the regex looks for the encoded value of '+' (\x2b), but not the encoded value of '='. It works either way:

"+and+1%3D1" <-- fires

"+and+1=1" <--fires

If I change the regex to:


It fires on either the literal '+' or the encoded version:



This Discussion