I am with you bros. An application firewall IMHO is nothing more than a data
validation component abstracted from the application architecture to a point
where it is architecturally less significant. Sorry just calling it like it
is IMHO. Any decent application architecture already has it (its called the
controller in STRUTS or MVC equiv's ;-)) hence the reason why the market
sector is not as hot as the venture capitalists thought (straight from the
mouth of a Tier 1 VC after finally talking to the big financial services
companies about his portfolio)). The best approach I have seen recently is
to build a reusable component into the servlet filter API (Ivan R. I will
let you share that if you feel comfortable) where you at least understand
the business logic. This is in line with best practice for a web application
architecture anyways, nothing revolutionary. The other approach is like
putting a sticking plaster over a heart attack! I am not saying they are
totally useless (actually the Netcontinnumm hardware type ones I have seen
are pretty fast and very useful as a hardware accelerated input filter),
just that they are nothing more than pre-packaged input validation
components.That's a good thing but some vendors should stop selling a Civic
(or Lexus in the case of the hardware ones (and by hardware that's not a
Linux appliance, its on the ASIC)) as a Ferrari. I am sure I need to be
"re-educated" my marketing depts. who know better but ..
I saw a vendors press release the other day where they claimed their web app
firewall would find all of the OWASP Top Ten. Poor crypto, sure! Poor
authorization (access control), sure! Dinis Cruz and I are happy to write an
application with 100% of the OWASP Top Ten and then stick any firewalls in
front of it that claim to find all the issues and see how they shape up (as
long as we are allowed to do it in public, publish the results as they
happen and unabridged). Its game on ! We know the results (some may find up
to 50% of the issues) but its time marketing spin is crushed before this
sort of stuff gets out of hand and we all can help get back to focusing on
the real issue, building better software. What there are no Silver Bullets,
shocker ;-)
And if someone claims it's the "learning mode", I am going to spend tomorrow
night knocking up a skunk works tool that unit tests a web site and builds a
white-list library for filtering so people don't fall for that as well.
Another issue also comes in the way these things are deployed. Data
validation (note not input validation) is not just about perimeter checking.
It should be at any crossing of a trust boundary. That maybe .NET remoting
calls, RMI, some serialization etc not the traditional HTTP request /
response.
Just for clarity the original post I made (way back when) was about a
reusable library called SecureObjects not application firewalls. I was
stating that I think the folks at SPI should be commended for being the only
scanning vendors to start to focus on building better software. Many other
exist including OWASP's OCL in Java or the OWASP Common Library. This
provides much of the security on the OWASP portal. I am kinda surprised no
one has shared their favorite security libraries in . NET in an open source
manner but that's another story.
SectorsThatDontLikeMe.add(appFirewallVendors);
-----Original Message-----
From: Sebastien Deleersnyder [mailto:sdl@ascure.com]
Sent: Wednesday, August 25, 2004 7:39 AM
To: Madsen, Villy; Mads Rasmussen; Mark Curphey
Cc: webappsec@securityfocus.com; Jeff Williams
Subject: RE: Finally - Curphey award 2004 to SPI Dynamics
Hi,
A bit late, but I am going through a pile of mail myself, and kicking in an
open door:
The problem with this kind of application level firewalls is that it can
protect you agains most common input validation mistakes, but when it comes
to design mistakes they will fail and only provide a false sense of security
(like the 'old' firewall story).
We should not fall in this trap a 2nd time: A have an (Application
Level) Firewall thus I should feel safe?
An application level firewall can provide defense in depth, but should not
replace proper security design/implementation throughout the whole SDLC.
Kind regards,
Sebastien
-----Original Message-----
From: Madsen, Villy [mailto:Villy.Madsen@atcoitek.com]
Sent: dinsdag 29 juni 2004 16:19
To: Mads Rasmussen; Mark Curphey
Cc: webappsec@securityfocus.com; Jeff Williams
Subject: RE: Finally - Curphey award 2004 to SPI Dynamics
While I do not advocate that Developers be allowed to get lazy about
security,
I also feel that providing a standard tool that they can use to filter input
is a bad thing.
Way back a couple of decades ago, I was involved in a Telco project to
rewrite an application used by Long Distance Telephone operators to
manage "Time and Charges" calls. The application was finally shut down
in 2000.
One of the "breakthroughs" that we pioneered was the heavy use of what was
we called Table Driven IO. All data input or output from the system was
defined by a set of mapping tables, that defined what the data could look
like, how long it was, and where it was mapped to in the application data
schema.
The "mapping" applications were general purpose, checked for proper type
- performing whatever data conversions where necessary, guarded against
overflows etc etc.
Sounds very similar to me.
I thought it was a great idea then, and I still do...
One application to vet (the mapping routine), and a bunch of tables to
validate.
Easier than validating all of the code snippets that are "accepting Input"
from the external world....
Villy
Villy Madsen ISP GSEC
Information Security
ATCO I-Tek
Bus: (780) 420-5093
Cell: (780) 975-0110
Fax: (780) 420-3916
Mailto:Villy.Madsen@atcoitek.com
The information transmitted is intended only for the addressee and may
contain confidential, proprietary and/or privileged material. Any
unauthorized review, distribution or other use of or the taking of any
action in reliance upon this information is prohibited. If you received
this in error, please contact the sender and delete or destroy this message
and any copies.
-----Original Message-----
From: Mads Rasmussen [mailto:mads@opencs.com.br]
Sent: Tuesday, June 29, 2004 5:47 AM
To: Mark Curphey
Cc: webappsec@securityfocus.com; Jeff Williams
Subject: Re: Finally - Curphey award 2004 to SPI Dynamics
Mark Curphey wrote:
Here I am, depressed at the prospect of filling in mountains of
expense claims from weeks of traveling and approving mundane mails to
webappsec about XSS after XSS and along comes a shining light. At last
an "application security" company that gets it ! Hats of to the folks
at SPI and the Curphey Award for 2004 for leading the industry down
the right path !
http://biz.yahoo.com/prnews/040628/clm006_1.html
Here is another link http://www.eweek.com/article2/0,1759,1617901,00.asp
I don't know about you guys but I have a bad feeling about this. I am not
sure this is the right path.
The article quotes Caleb Sima, founder and chief technology officer of SPI
Dynamics saying "It doesn't require developers to learn about security," -
"You really just need to validate input to eliminate most application
vulnerabilities."
Shouldn't you at least have a feeling for where the developers makes their
mistakes to be able to insert the right piece of secure code?
By all means it looks like a cool product, but how much can we trust it?
One of its features is, qoute
"Input Validation objects will check incoming data on web forms to validate
user-supplied input against a set of rules and prevent parameter
manipulation exploits, such as SQL Injection attacks."
Can we trust these "set of rules".
If they opened their technology, the OWASP team could contribute rules to
such a database and then we just might get somewhere by having a list
of f.ex regular expressions for using the validator classes in .Net or input
validation in general but that would probably not happen.
I am concerned that products like this just leads to lazy developers.
Jeff what do you think about this? You wanted to start an input validation
project based on filters, a database like described above would be quite
handy :o)
Just my two bits
--
Mads Rasmussen, M.Sc.
Open Communications Security
www.opencs.com.br
+55 11 3345 2525
