A few more attempts...

3 replies
ericl
ericl's picture
Joined: 05/28/2008
User offline. Last seen 2 years 7 weeks ago.

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...

yuli
yuli's picture
Joined: 01/30/2008
User offline. Last seen 2 days 2 hours ago.

Hi Ericl

Thanks again for your additional report. I fixed || and && tokens. Now they are handled as expected. I updated demo version running at this site with the fixes.

GreenSQL is good at analyzing distinct SQL expressions (those separated by AND / OR). Currently it does pour job at correlating a number of SQL expressions. I have an idea how to do it efficiently. I am trying to lower number of of false alarms that this algorithm can generate.

Currently, if attacker has good knowledge of internal table structure, he can bypass GreenSQL risk algorithm. In order to do it, an attacker must know column names, like in the example you provide:

u: admin' or name='admin
p: test

With the bug report you provide we make a significant step towards building best database security solution. I will be happy to receive all your suggestions and bug reports.

Thanks,
Yuli

ericl
ericl's picture
Joined: 05/28/2008
User offline. Last seen 2 years 7 weeks ago.

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.

yuli
yuli's picture
Joined: 01/30/2008
User offline. Last seen 2 days 2 hours ago.

Thanks Eric

I will fix it ASAP.

Back to top