Oh my dear dear friend Richard, never underestimate the inability of developers – if the language has support for violating good security development considerations – they will find a way to use that to create a vulnerability. In any event you’d have to look at the mission statement of libinjection – it is certainly possible and shouldn’t be used alone. It does have a very specific mission, for instance it is not designed to take cookies and separate them or request headers etc. That being said I do like libinjection I think it’s inclusion does add rather than retract from the ModSecurity suite and if you can make it better you are more than encouraged to try. :)
From: Richard Lin <hongping...@hotmail.com<mailto:hongping...@hotmail.com>> Date: Thursday, February 11, 2016 at 12:50 PM To: Chaim Sanders <csand...@trustwave.com<mailto:csand...@trustwave.com>>, "owasp-modsecurity-core-rule-set@lists.owasp.org<mailto:owasp-modsecurity-core-rule-set@lists.owasp.org>" <owasp-modsecurity-core-rule-set@lists.owasp.org<mailto:owasp-modsecurity-core-rule-set@lists.owasp.org>> Subject: RE: [Owasp-modsecurity-core-rule-set] Need suggestion for a SQLI pattern 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<mailto:csand...@trustwave.com> To: hongping...@hotmail.com<mailto:hongping...@hotmail.com>; owasp-modsecurity-core-rule-set@lists.owasp.org<mailto: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<mailto:hongping...@hotmail.com>> Date: Thursday, February 11, 2016 at 1:06 AM To: Chaim Sanders <csand...@trustwave.com<mailto:csand...@trustwave.com>>, "owasp-modsecurity-core-rule-set@lists.owasp.org<mailto:owasp-modsecurity-core-rule-set@lists.owasp.org>" <owasp-modsecurity-core-rule-set@lists.owasp.org<mailto: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<mailto:csand...@trustwave.com> To: hongping...@hotmail.com<mailto:hongping...@hotmail.com>; owasp-modsecurity-core-rule-set@lists.owasp.org<mailto: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<mailto:owasp-modsecurity-core-rule-set-boun...@lists.owasp.org>> on behalf of Richard Lin <hongping...@hotmail.com<mailto:hongping...@hotmail.com>> Date: Wednesday, February 10, 2016 at 7:31 PM To: "owasp-modsecurity-core-rule-set@lists.owasp.org<mailto:owasp-modsecurity-core-rule-set@lists.owasp.org>" <owasp-modsecurity-core-rule-set@lists.owasp.org<mailto: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<http://scanmail.trustwave.com/?c=4062&d=9cq81m-50sHLrlIm_iaLgMaFk8OtgRkZLr5vbovmVg&s=5&u=http%3a%2f%2ftest%2ecom%3fid%3dselect> 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.<http://scanmail.trustwave.com/?c=4062&d=9cq81m-50sHLrlIm_iaLgMaFk8OtgRkZLu1gaYy7Uw&s=5&u=http%3a%2f%2ftest%2ecom%3fid%3dselect%20a%20from%20table%20b>" > 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. ________________________________ 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
