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.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.