<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 1/11/2010 3:42 PM, John Steven wrote:<br>
<br>
> As a last resort, might I suggest using inheritance and
encapsulation to stitch together framework-provided cut points and
ESAPI code. <br>
<br>
This is where ESAPI will evolve. For starters, we need to get our base
controls right. :) This is the hallmark of complicated engineering
fields like robotics - start small, get it working and add complexity
over time.<br>
<br>
> For instance, one can simulate [the dreaded] 'multiple
inheritance' of both Struts and ESAPI base classes by using the
template method pattern within a sub-class of (say) the struts-provided
class, which, implementing the template method pattern, would call
security controls (such as validation or the largely vestigial ESAPI
authentication checks) before handing off to end-application developer
code that handles other controller functionality/business logic.<br>
<br>
Interesting. Keep in mind, template pattern implies some kind of shared
functionality. I would not call interfaces (ie: Java's substitution for
standard multiple-inheritance) dreaded when used appropriately.
Interfaces are "clean" and do not carry any baggage (ie:
functionality). It's my opinion that the ESAPI interfaces are ESAPI's
gold - we are trying to suggest a few (100 or so) methods that you
organization needs to have at the app level (in some form or another)
in order to build secure apps. Template pattern might be more
appropriate for a C+ ESAPI, but not Java, IMO, in this specific case.
Each language-specific version of ESAPI will mandate different
patterns. But once we start the ESAPI-Struts and the ESAPI-Spring
project, which will happen, template will resurface.<br>
<br>
Taking a step back - let's take the common notion that we live in a
"framework world" and dismiss it. The reality is, many large
organizations depend on completely heterogeneous software
architectures. I've seen one large org use multiple versions of struts,
swing and wicket, in addition to several custom architectures, in
addition to old school servlets, using several different servlet
containers including one in which they built their own servlet
container from scratch and continue to maintain it. This is where an
ESAPI is ideal - a common set of centrally maintained controls to pull
from.<br>
<br>
> Personally, for me, the strategy of tacking ESAPI calls onto a
developer's application code manually on a case-by-case basis without
techniques described above is bound for failure. <br>
<br>
I think "bound for failure" is an almost dangerous exaggeration.
Difficult (at first) and even error prone? Possibly. Deep framework
integration of all of these controls will take time. I originally
wanted to make ESAPI a struts project - and just go mad in submitting
patches to struts. After ESAPI reaches a measure of stability, I may do
just that (ESAPI-Struts!). <br>
<br>
Also, (your) ESAPI should be part of a well balanced software
engineering life-cycle. You need to trust developers to some degree to
do the right thing. Trust but verify. This is where code guidelines,
code review (and I do not mean security code review, just plain ol
review of developers code to ensure they are writing to corporate
standards) and other non-security code quality and functionality review
techniques come into play.<br>
<br>
> Developers simply won't be able to reach the total consistency
required for robust defense in a large existing application. <br>
<br>
Well, that speaks of a larger problem - if your coders are all "coders
gone wild"- then you are in trouble even before the auditors arrive.
Consistency of your codebase is your organizations, architects and
other software leaders job. <br>
<br>
> If you're going to walk this road though for the love of God
please deploy SAST to make sure that something is sweeping through and
looking for that ever-elusive consistency of application I describe. <br>
<br>
SAST is a decent value, in some cases, when approaching very insecure
code-bases. Turnkey SAST is a waste of money on a mature code base -
without custom rules specific to your conventions and controls. And for
a very large company? I think <b>not </b>moving in the direction of
some kind of SAST technology - whether its off the shelf or custom
built - is crazy in this day in age. You need some measure of automated
code review, but doing it cost effectively can be illusive. Findbugs is
a great place to start in the Java world. A few RegEx's specific to
YOUR controls and styles go a long way. And if you can afford it, going
whole hog on one of the major commercial SAST players with custom rules
is not a terrible idea, if you have the AppSec FTE's or consultants
available to run and interpret the results. The open source world is
behind but will catch up. I know I'm mixing ideas here, but you get
the gist. And these are loaded ideas, I'm curious to hear your response.<br>
<br>
> I'd be very-much interested in data regarding faster and cheaper.
With the exception of the input validation, canonicalization, and
related functionality (*5) it seems like a lot of analysis and
integration jobs remain when adopting ESAPI. <br>
<br>
It took me about 8 hours to port the flat-file authenticator to a
high-performance hibernate solution. Perhaps another 16 hours of code
tweaking. I'm not a fan of the ESAPI authenticator as it stands today
and I would like to see it evolve. But porting the reference
implementation forced me to do it "right" and it did not take long at
all. Calling it vestigial is certainly and exaggeration, IMO.<br>
<br>
> I'd also like to know about bug rates relative to non-ESAPI code.
I've been on the ESAPI mailing list for a while and can't discern from
conversation much information regarding successful operationalization,
though I hear rumblings of people working on this very problem. <br>
<br>
It difficult to do this without violating non disclosures with clients.
But I agree, we need these stats!<br>
<br>
And I need to be careful here. The world is a very meaningless place if
you over-analyze it. I'm in the trenches trying to support the
developers who are donating their time to build open source security
libraries in order to make the world a better place in some small way.
My personal goal is to make the entire application security industry
disappear and/or shrink so AppSec is just a standard set on line items
on each software projects SOW. Communists? Maybe. But we are making a
difference.<br>
<br>
These are all my opinions and do not necessarily represent the
"official" position of OWASP, if such a thing even exists (yet). <br>
<pre class="moz-signature" cols="72">--
Jim Manico
OWASP Podcast Host/Producer
<a class="moz-txt-link-freetext" href="http://www.manico.net">http://www.manico.net</a></pre>
</body>
</html>