Thanks Chaim and Christian and I agree that it is bad that a user controls a 
SQL statement.  I think libinjection covered 'Where' and 'Like' clause as you 
mentioned.  
I am trying to judge if libinjection missed a category of attacking model in 
which the user's input is an independent SQLs which can be invoked by 
themselves (i.e, without prefix of "1 UNION", '1 or", "1 and", etc)  If that is 
the case, I would consider to propose a patch. But I am not sure how careless 
developers can directly take the input as SQL itself. That sounds too naive to 
be believed :)

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 13:28:40 +0000






Hey Richard, first I’ll echo what Christian said, but also what you have 
described is just a LIMITED case of SQL injection. SQL Injection can really 
deal with any area in which SQL may be introduced by an attacker and it will
 then be executed later. There is no need to limit this to a where clause. For 
instance it could be in a like clause, it could be the clause itself, it could 
be the statement (select for instance) etc. The underlying idea is that 
anywhere a user can control
 a SQL statement would be bad. In fairness to libinjection it isn’t factoring 
in all these situations it is designed with parameters in mind and SQL 
injections more a kin to the type you are describing. This is why we leave in 
complex regex patterns as well
 that can detect SQL patterns like the one you have described.
Another situation where it would be valuable to detect such statements would be 
in the case of stacked sql queries. Although not all engines support it, in 
some you may so things like:



select * from User where id =  [ input] to select * from User where id = 1; 
select a
 from uid2




These are good questions and from these often we’ll discover other facets of 
the problem or solutions we never thought of so please feel free to keep asking 
if you have any ideas or questions, or are unclear on something :)









From: Richard Lin <hongping...@hotmail.com>

Date: Thursday, February 11, 2016 at 1:06 AM

To: Chaim Sanders <csand...@trustwave.com>, 
"owasp-modsecurity-core-rule-set@lists.owasp.org" 
<owasp-modsecurity-core-rule-set@lists.owasp.org>

Subject: RE: [Owasp-modsecurity-core-rule-set] Need suggestion for a SQLI 
pattern







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.











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

Reply via email to