oss-sec mailing list archives
Re: "The Blind SQL Injection Issue" explanation
From: Solar Designer <solar () openwall com>
Date: Wed, 1 Jun 2016 14:53:48 +0300
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
Current thread:
- "The Blind SQL Injection Issue" explanation Mihamina RAKOTOMANDIMBY (Jun 01)
- Re: "The Blind SQL Injection Issue" explanation Solar Designer (Jun 01)