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}
