Ramesh Nagappan Blog : Java EE 6: Web Application Security made simple ! | Core Security Patterns Weblog

[jim.manico at owasp.org (Jim Manico)]

On 1/11/2010 3:42 PM, John Steven wrote:

> As a last resort, might I suggest using inheritance and encapsulation
to stitch together framework-provided cut points and ESAPI code.

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.

> 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.

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.

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.

> 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.

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!).

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.

> Developers simply won't be able to reach the total consistency
required for robust defense in a large existing application.

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.

> 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.

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 *not *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.

>  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.

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.

> 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.

It difficult to do this without violating non disclosures with clients.
But I agree, we need these stats!

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.

These are all my opinions and do not necessarily represent the
"official" position of OWASP, if such a thing even exists (yet).

-- 
Jim Manico
OWASP Podcast Host/Producer
http://www.manico.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100112/d49deab8/attachment.htm>