[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20160601115348.GA22607@openwall.com>
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.
