Date: Wed, 1 Jun 2016 14:53:48 +0300 From: Solar Designer <solar@...nwall.com> To: Mihamina RAKOTOMANDIMBY <mihamina-rakotomandimby@...mb.org> Cc: oss-security@...ts.openwall.com Subject: Re: "The Blind SQL Injection Issue" explanation Hi Mihamina, Your message lacks open source focus (is your web app open source? as far as I can tell, the security scanner in question is not) and you posted the same question to Security Basics, so as a list moderator I was reluctant to approve it. Next time, please post content that is more obviously on topic for oss-security, or clarify how whatever you're posting is on topic. If you can't, then please refrain from making borderline postings like this. Security Basics, judging by its name, is probably a more appropriate place for your question, but it looks rather inactive, I don't know why - no community interested in discussing security basics on a mailing list? If anyone in here has suggestions on an appropriate mailing list for questions such as this, please share. Maybe full-disclosure, which is used for lots of stuff, even though this is a question and not a disclosure? On Wed, Jun 01, 2016 at 02:15:41PM +0300, Mihamina RAKOTOMANDIMBY wrote: > Let's suppose the web app is vulnerable, the reasoning of this test is: > > - req. 1 gets resp. 1 and changed database state to state 1 > - req. 2 gets resp. 2 and changed database state to state "whatever" > - req. 3 gets resp. 1 and changed database state to state "whatever" > > My questions are: > - How could database state "whatever" would give the same response as > "state 1" ? (a.k.a "resp. 1") I can't speak for authors of a proprietary security scanner, but I guess the assumption is that the queries are such that the database state does not change (at all, or at least not in a way affecting these specific queries). If the database state changes (in a relevant way), then a possible difference in responses to requests 1 and 2 does not indicate SQL injection, but more likely indicates a false positive, so the purpose of request 3 may be to weed out such false positives (ensure the state has not changed from request 1 to request 3, and thus the different response to request 2 more likely indicates SQL injection rather than a change in response occurring between subsequent requests in general). This is just a guess, which might be wrong. > - As a "blind" one (mostly random input then), how could these > assertions work? "Blind" does not mean "mostly random input". Alexander
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ