I have sat back for the last 12 months and watched threads like this fly
past my head. After this mail I will do the same but I somehow feel
compelled to respond and get a few things of my chest. I am not trying to be
controversial or confrontational, just offer a balanced approach to the
debate. These are my personal opinions and "yes" I already know that more
than enough product vendors already don't like me for being very vocal about
my opinions on these things. Quite frankly I don't care. Freedom of speech
baby, I just say it like it is and I am not sorry if that halters your
ability to sell cotton candy and moon dust.
1. Automation (both protection and detection)
2. Thinly disguised marketing posts in public lists
1. Automation
Firstly I 100% agree on the desire to automate as much security testing and
protection as is possible; that much is undisputed. Before we look at the
automation of both assessment and protection lets first scope the extent of
the software security problem. Many of the issues brandished around in
marketing and the press seem to intimate that data validation is the extent
of the software security problem (in fact it's a lot worse than that with
most people only considering input validation). While these attacks that
exploit insufficient or inappropriate data validation are of course way too
prevalent there is a distinct bias in the media and on lists like bugtraq.
You have to be pretty damn silly to build an app in ASP.NET and have a SQL
injection issue these days (even my level of development which is pretty
basic its hard to slip up). The bias comes in when you look at the amount
of php based software that is written by very inexperienced developers
appearing in advisories. The low cost of entry (while admirable) inevitably
will lead to more issues in software created in the big picture. This
software however generally (note generally not exclusively) tends to have
very limited deployment and is not representative of what is found in the
commercial world.
At Foundstone we have tested literally thousands of apps and the most
frequent and most insidious issues are rarely data validation issues these
days. They were a few years back but not today. They are issues with
authorization systems, user management systems, business logic, data
protection in (storage and transport), broken protocols, badly implemented
cryptography and such like. The bar has been raised.
So if we are interested in systems to help test and protect bespoke software
we should first consider the scope of the issues. This is a key point.
Software security problem does not equal input validation.
Protection systems or web app firewalls. These tend to be some sort of
intelligent proxy that intercepts the data steam and applies a set of rules
(sig based or heuritics). These tools are only good for data validation
IMHO. They have no hope whatsoever to protect a web application where say
switching a name value pair gives you another persons account. They have no
hope in detected poorly implemented cryptographic algorithms or key
management systems. They are dealing with a very very limited scope of the
problem.
Not only that but IMHO they are architecturally in the wrong place. There
are many options for data validation. In order from left to right you can do
it in the code, in a framework (STRUTS), at the web server (ISAPI, NSAPI) or
on the network (web app ids). The further away from the code the less
control you have over the validation. This is common sense. Validation is
about context. You can't simply say don't let a ' hit the app. What about
poor Rosie O'Grady. You have to build context based validation to be
effective. The closer you are to the code the more control, more precision
and more flexibility you have. The further way you are the less control,
less precision and less flexibility you have. The closer to the code the
better, the further away the worst off you are.
We have driven trucks past every major web app firewall I know about. When I
see marketing from the likes of Imperva stating they defend against the
OWASP top ten I just ROFL. Poor use of crypto. Its just total hog wash.
Repeat we have driven trucks past every major web app firewall I know about.
I can write a simple app with a catastrophic vulnerability (total control of
the system) that you can not protect against with a data stream analysis
approach. That in itself is why I would never buy one and never recommend to
others they do either. It's a hyped market. As a SMALL part of a layered
approach there is obviously value.
A few people keep asking me where I think validation should be done. I
always say in the code. The argument sometimes comes back that that's not
always possible. While I completely disagree (every commercial company I
have worked for has a release cycle of every few weeks and consistently
changes the code base so either I have been living under a rock in major
financial services companies or the vendors marketing thought they had a
good sales angle) I challenged some of my guys at Foundstone to offer an
alternative to code based validation. On March 8th we will release the
Foundstone .NET Security Toolkit for free (with source under an Apache
license) with two tools. This is a "proof of concept toolkit" to prove other
approaches and ideas. Think of it as the D in R&D. One tool is Validator.NET
that uses the reflection API in .NET to systematically determine some inputs
to a web application and build a rule set in XML. You can then load this
into an HTTP module (also in the toolkit). No source needed and free. Also
the a few steps closer to the code than the http proxy based web app
firewall! We think we can do the same for Java as well.
The same is true of automated testing, especially pen testing. I personally
firmly believe that the most cost effective and efficient way to test
software is to use the code. To say that code review is too expensive is
misleading and outright wrong. It's a common misconception perpetuated by
the uneducated. I wrote an article about it at www.softwaremag.com. Pen
testing web apps is a Turing problem, the number of inputs has to equal the
number of outputs and that's computationally unfeasible in a modern app. For
low hanging fruit its great but for the type of issues being found now the
bar has been raised I don't think its appropriate. Again at work we have
driven trucks past app that have been given a clean bill of health by the
scanners. And that's pretty frequent not an edge case BTW. If you look at
code analysis tools as well they are getting good at finding bugs like
overflows but flaws like people using poor PRNG or storing keys in config
files they are next to hopeless. Guess what, flaws are the most insidious
type of issue we find. Its not that these tools are of no value. We use
automated tools for code review and will likely buy or build something for
web app pen tests this year. For the LHF it's a no brainer. The point is any
automated solution is a subset of the problem space. At the moment I would
say its less than 25% for the web app firewall space and about 20% for the
pen test space (gut feeling). We will also be releasing Hacme Books (think
Hacme Bank but a full Java version that looks like Amazon (properly
architected)) on March 8th which shows similar results if you scan it with a
scanner.
And today I don't even want to get started about automated tools helping
with compliance like GLBA and HIPPA. That's so laughable its not worth the
electrons. Dreamt up in marketing land.
Which leads me neatly onto;
2. Thinly disguised marketing posts
This is just a mater of taste but I have become so skeptical of articles ad
posts on mailing list now. "I think x and BTW I happen to make a product
that does exactly this". The worse are the ones that say "BTW only we have a
solution that does this". I have seen articles in the likes of eWeek that
are just pure product pitches. I have also had articles rejected from the
trade press as it would have "not been good to keep the advertisers happy".
Buyer beware! Not all you read is true.
-----Original Message-----
From: Ofer Shezaf [mailto:ofer@shezaf.com]
Sent: Saturday, February 19, 2005 3:50 PM
To: webappsec@securityfocus.com
Subject: RE: ISA Server and SQL Injection
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}
