Richard, You are on good tracks with your reasoning.
What LibInjection is doing is feeding your input string into an sql parser and check if it results in a possible injection. Obviously, your input string _is_ sql, which gives reason to believe that libinjection is combining your string with predefined strings first. Much like you do in your message. The problem is, that libinjection is underdocumented from a technical viewpoint so all I am writing here is based on fairly highlevel presentations. The takeaway for me is that not even libinjection is a silver bullet. It catches a lot, but there are dark areas where it has to be combined with regexes in a diverse approach. Ahoj, Christian On Thu, Feb 11, 2016 at 06:06:35AM +0000, Richard Lin wrote: > Thanks. Could you explain in more detail? > My understanding for SQL injection case is that careless web developers take > the web request parameters and add them to their "where clause". > So if the input is '1 union select a from uid2" that would cause successful > injection because the careless developer's SQL was modified from > select * from User where id = [ input] to select * from User where id = 1 > union select a from uid2 > In above case, the SQL statement was successfully modified with correct > syntax. Thus I can accept this is a successful injection. > But if the input is "select a from uid2", then careless developers SQL is as: > select * from User where id = select a from uid2 > The above SQL statement is not correct in syntax. So this injection will not > be successful. Maybe due to this consideration, the libinjection does not > consider input of "select a from uid2" is a SQL injection although its SQL > pattern is so obvious. > Richard > > From: csand...@trustwave.com > To: hongping...@hotmail.com; owasp-modsecurity-core-rule-set@lists.owasp.org > Subject: Re: [Owasp-modsecurity-core-rule-set] Need suggestion for a SQLI > pattern > Date: Thu, 11 Feb 2016 02:51:44 +0000 > > > > > > > Hey Richard, > I’ve seen things CLOSE to this in production. Sites where they’ve attempted > to use prepared statements to secure a location where the variable injected > in a table name. Of course prepared statements are designed for this > environment and will fail miserably. > But this accounts for a situation where all of the following except the word > select is true. Granted it’s unusual. > > > > > > From: <owasp-modsecurity-core-rule-set-boun...@lists.owasp.org> on behalf of > Richard Lin <hongping...@hotmail.com> > > Date: Wednesday, February 10, 2016 at 7:31 PM > > To: "owasp-modsecurity-core-rule-set@lists.owasp.org" > <owasp-modsecurity-core-rule-set@lists.owasp.org> > > Subject: [Owasp-modsecurity-core-rule-set] Need suggestion for a SQLI pattern > > > > > > > > > Hi folks, I just joined the lists one day ago. And would like to seek the > opinions of dealing with a SQLI pattern verdict-ed differently between regex > rules and libinjection. > > > > http://test.com?id=select a from table b. > > > > I did not make SQLI "select a from table b" as URL encoded for easier > discussion here. > > > > Basically, libinjection does not consider this string as SQLI although its > SQLI pattern is so obvious. Libinjection considers the SQL injections are > typically in the context of > > > > > select * from table where id =%input with or without injection% > > > > > > > >From libinjection point of view, the input of "select a from table b" is > >unable to join the above statement with correct SQL syntax. But if we just > >use regex rules, this input is so easy to marked as SQLI. I would > like to seek the opinion in this group. Do you think the request as > "http://test.com?id=select > a from table b." would cause really SQL injection successful in SQL syntax > in any site? > > > > Thanks > Richard > > > > > > > > > This transmission may contain information that is privileged, confidential, > and/or exempt from disclosure under applicable law. If you are not the > intended recipient, you are hereby notified that any disclosure, copying, > distribution, or use of the information > contained herein (including any reliance thereon) is strictly prohibited. If > you received this transmission in error, please immediately contact the > sender and destroy the material in its entirety, whether in electronic or > hard copy format. > > > _______________________________________________ > Owasp-modsecurity-core-rule-set mailing list > Owasp-modsecurity-core-rule-set@lists.owasp.org > https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set -- mailto:christian.fol...@netnea.com http://www.christian-folini.ch twitter: @ChrFolini _______________________________________________ Owasp-modsecurity-core-rule-set mailing list Owasp-modsecurity-core-rule-set@lists.owasp.org https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
