Hi Richard and others, Actually your original query (passing “select A from B”) might even be successful in some cases. For instance, in MySQL, you can have a subquery. However it must appear in parentheses.
For instance this is a valid query: select * from user where id=(select id from user where admin=1) So if an application developer does the following, your statement might get executed: select * from user where id=(injected_parameter) Now, the libinjection in ModSec 2.9 still tries to do something. It doesn’t think this is SQLi: "select id from user” (your example) “delete from foo" But it does think the following strings are SQLi: "(select id from user)” "select id from user where admin=1” "select id from user where password is null” It’s still bit of a black box, but I’m collecting many samples and I plan to report any possible coverage test caseas upstream. I think your example is an interesting one that may not cause too many vulnerabilities, but an application that accepts full queries is still very hazardous so in my opinion ideally libinjection should trigger on it. Cheers! WH > On 11 Feb 2016, at 18:50, Richard Lin <hongping...@hotmail.com> wrote: > > 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 :) > -- Walter Hop | PGP key: https://lifeforms.nl/pgp
_______________________________________________ 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
