RE: ISA Server and SQL Injection

[Ofer Shezaf <ofer () shezaf com>]

Unfortunately there are no blacks and whites, and answers are usually
somewhere in the middle.

I agree with Matthieu that in many cases programmers are not good enough,
patches for internally developed software are non-existing and code review
is too expensive to be done for every line of code.

On the other hand automated application security is not easy either. Most
signature based systems will have hard time blocking SQL injections and
other application layer attacks. While 'select' is way to prone to produce
false positives (read: block legal users), '1=1' is much two weak as it is
just an example: any '1=1' expression can be replaces by '2>1' and hundred
others. And on the other hand application firewalls which employ a white
list mechanism that allow only specified input are difficult to implement in
a manner which is secure enough.

This does not mean any of the solutions is bad; it is just that, like
everything in security (and in life?) none is perfect. In my opinion
Patching, code review and security testing should always be done, but a real
time application security solution is also an important option. I also think
that these systems are getting better and are starting to evolve from either
simple signature based or white list based systems to more effective hybrid
systems.


Ofer Shezaf
CTO, Breach Security

Tel: +972.9.956.0036 ext.212
Cell: +972.54.443.1119
ofers () breach com
http://www.breach.com

> -----Original Message-----
> From: Matthieu Estrade [mailto:mestrade () apache org]
> Sent: Friday, February 18, 2005 1:17 PM
> To: webappsec () securityfocus com
> Subject: Re: ISA Server and SQL Injection
>
> Sebastien Deleersnyder wrote:
>
> > > -----Original Message-----
> > > From: Matthieu Estrade [mailto:mestrade () apache org]
> > > Sent: donderdag 17 februari 2005 14:58
> > > To: webappsec () securityfocus com
> > > Subject: Re: ISA Server and SQL Injection
> > >
> > >
> > > Yes sure, if you code application using in parameter some SQL query,
> > you should read "howto do secure code for
> >
> >
> > > webapp"....
> > > Application mainly use value after used by the application inside a
> > query, but the query is in the code.
> >
> >
> > > http://www.toto.com/test.php?product_id=4 is ok and there is NO WAY to
> > see here some SQL Syntax.
> >
> >
> > Be aware that the above parameter can directly be used to build up the
> > SQL query such as
> > SQLParam= "SELECT * FROM products WHERE productid = " &
> > getParam("ProductId")
> > This poses a danger when the 4 is replaced by "4 and 1=1" => gives back
> > all the rows of the product table.
> > You can imagine disaster scenario's with e.g. patient health data that
> > is displayed.
> > Also this will allow an attacker to provoke errors and from the
> > errormessages deduct the table(s) structure, etc ...
> >
> > One of the best ways to prevent SQL injection is to build parameterized
> > queries that will limit the variable data types used!
> I agree, but if the web app fw see a "AND" + "1=1",  he should block.
> AND is a part of SQL Syntax.
>
> > > http://www.toto.com/test.php?product_id=SELECT%20*%20FROM%20product%20W
> > HERE
> >
> >
> > > %20id=4 is not ok, and you shoud fire developper doing this....
> > >
> > > Using parameters values doing directly actions is "HACKER FRIENDLY!"
> >
> > This is indeed not a good idea! But instead of firing, the developper
> > should get educated.
> sorry yes, but i am not sure many developpers do this nowadays, so
> nobody will be fired.
> It was more to say that seeing an SQL query into a safe request is
> really rare so it can be protected by a webappfw blocking on SQL Syntax
> pattern matching.
>
>
> > --- infosecurity.be ---
> > Bezoek ons tijdens Infosecurity.be 2005 op 23 of 24 maart in Brussels
> Kart Expo.
> > Registreer vooraf en ontvang uw gratis toegangskaart via:
> > http://www.databadge.net/isbe2005/reg/?link=4dd995bba9ac221908f3
> >
> > Voor meer info:
> > http://www.ascure.com/default.asp?type=Eventsdetail&id={4D6980F0-651A-
> 419A-93AF-E9EB42F74651}&lang={00000000-0000-0000-0001-000000000001}
> >