hi.
with the last commit (3761) false positives tests are implemented
(small Turing like arithmetic tests).
this means that now there should be far lesser problems like this
reported by Ahmed.
kr
On Thu, Apr 21, 2011 at 11:19 AM, Miroslav Stampar
wrote:
> hi all.
>
> to deal with this kind of
hi all.
to deal with this kind of situations (FALSE positives) we've agreed
internally to run a confirmation phase right after detection phase
for:
A) when only blind injection is detected (like in Ahmed's case,
especially pain in the ass are search engine queries)
B) when only time and/or stacked
nevermind the last message.
this is particular case and i'll try to deal with it.
thing is that the returned page for AND 1=1 was really too similar to
the original (match ratio 0.973) and together with comparison against
response of 1=0 it triggered FALSE positive.
kr
On Wed, Apr 20, 2011 at 3
hi all.
here we have a pretty "interesting" problem. ahmed sent me privately
the url and it really seems like a FALSE positive.
but this one is pretty annoying and not so obvious to solve.
thing is that the tested "search" parameter with payload "bla AND 1=1"
displays totally different results t
hi Ahmed.
could you please retry with --flush-session and --text-only and report back?
kr
On Wed, Apr 20, 2011 at 7:06 AM, Ahmed Shawky wrote:
> sqlmap display the output in strange way something like
> available databases [1]:
> [*] ][[[][A[]][][][[][]B! QCR Q]C
> the used flags are -t log
sqlmap display the output in strange way something like
available databases [1]:
[*] ][[[][A[]][][][[][]B!QCRQ]C
the used flags are -t log.log --level 3 --risk 3 --dbs
info:
Place: GET
Parameter: q
Type: boolean-based blind
Title: AND boolean-based blind - WHERE or HAVING clause
