Re: "The Blind SQL Injection Issue" explanation

[Solar Designer <solar () openwall com>]

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