[Snort-sigs] Generic SQL injection false positives

Guise McAllaster guise.mcallaster at ...2420...
Mon Dec 28 19:15:53 EST 2009


Sure:

http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/

Search for "/**/"

A good point somebody says is that we need to know what exactly the
URL normalization is done so we can know what it eliminates.  Some
like "%20" and "+" or "++" are sure recognized but others?  What are
they?

Snort has been victim to some bypasses in the past (no offense, VRT).

Guise

On 12/28/09, Paul Schmehl <pschmehl_lists at ...3425...> wrote:
> Can you provide an example of that?
>
> --On December 28, 2009 4:15:20 PM -0600 Guise McAllaster
> <guise.mcallaster at ...2420...> wrote:
>
>>
>> From what I've seen, some SQLi will work using "/**/" instead of
>> spaces.  Other bypasses are possible as well I thinks.  Others want to
>> contribute some useful bypasses to spaces?
>>
>> Guise
>>
>> On 12/28/09, Paul Schmehl <pschmehl_lists at ...3425...> wrote:
>>> --On December 28, 2009 12:10:37 PM -0600 Matt Olney
>>> <molney at ...435...> wrote:
>>>
>>>> I see a lot of false positive for generic SQL injection rules.  For
>>>> example, SID 13514 shown here:
>>>>
>>>> alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"SQL
>>>> generic sql update injection attempt"; flow:established,to_server;
>>>> content:"update"; nocase; pcre:"/update[^\n]*set/i"; metadata:policy
>>>> security-ips drop, service http;
>>>> reference:url,www.securiteam.com/securityreviews/5DP0N1P76E.html;
>>>> classtype:web-application-attack; sid:13514; rev:4;)
>>>>
>>>> Alas it alerts for normal traffic like this:
>>>>
>>>> GET /get_updates_1/assessment/frameset_yellow.asp  HTTP/1.1
>>>
>>> I don't see how a sql injection attempt is going to begin with any
>>> character other than a space preceding it.  How would the sql engine be
>>> able to parse that?  ISTM that the update could simply be anchored on
>>> both sides; e.g pcre:"$update^/i";  For update to work, the only thing
>>> that can be on either side of it is a non-alpha character or a single
>>> quote, which the sql parser will discard.  If you want to include set
>>> (which makes sense), I would make it a separate detection.  A typical
>>> update statement would be UPDATE table SET blah='foo' where blah='bar'
>>> or blah like '%doo%';
>>>
>>> Something like this would be better, in my opinion.
>>>
>>> alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"SQL
>>> generic sql update injection attempt"; flow:established,to_server;
>>> content:"update"; nocase; pcre:"/$update^/i"; content:"set"; nocase;
>>> pcre:"/$set^/i"; metadata:policy security-ips drop, service http;
>>> reference:url,www.securiteam.com/securityreviews/5DP0N1P76E.html;
>>> classtype:web-application-attack; sid:13514; rev:5;)
>>>
>>> Mind you, I haven't tested it, but it would certainly eliminate the
>>> false positive given in the example.
>>>
>>> Paul Schmehl, If it isn't already
>>> obvious, my opinions are my own
>>> and not those of my employer.
>>> ******************************************
>>> WARNING: Check the headers before replying
>>>
>>>
>>> -----------------------------------------------------------------------
>>> ------- This SF.Net email is sponsored by the Verizon Developer
>>> Community Take advantage of Verizon's best-in-class app development
>>> support A streamlined, 14 day to market process makes app distribution
>>> fast and easy Join now and get one step closer to millions of Verizon
>>> customers http://p.sf.net/sfu/verizon-dev2dev
>>> _______________________________________________
>>> Snort-sigs mailing list
>>> Snort-sigs at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/snort-sigs
>
>
>
> Paul Schmehl, If it isn't already
> obvious, my opinions are my own
> and not those of my employer.
> ******************************************
> WARNING: Check the headers before replying
>
>




More information about the Snort-sigs mailing list