All,

With due respect to those who work on ESAPI, Jim included, ESAPI is not the 
only way "to make a secure app even remotely possible." And I believe that 
underneath their own pride in what they've done--some of which is very 
warranted--they understand that. It's hard not to become impassioned in posting.

I've seen plenty of good secure implementations within organizations' own 
security toolkits. I'm not the only one that's noticed: the BSIMM SSF calls out 
three relevant activities to this end:

SDF 1.1 Build/publish security features (*1)
SDF 2.1 Find/publish mature design patterns from the organization (similar URL)
SDF 2.3  Build secure-by-design middleware frameworks/common libraries (similar 
URL)

Calling out three activities within the SSF means that it can't just be "John 
Steven's top client" (whatever that means) that's doing this either. I've 
formally reviewed some of these toolkits and I'd pit them against ESAPI and 
expect favorable results. Plenty of organizations are doing a great job 
building stuff on top of profoundly broken platforms, frameworks, and 
toolkits... and they're following a 'secure SDL' to get there. ESAPI can not be 
said to have adhered to that rigor (*2). Organizations care about this risk 
regardless of the pedigree and experience of those who are building it.

Is the right answer for everyone to drop everything and build their own secure 
toolkit? I don't think so. I like that the OWASP community is taking a whack at 
something open and free to share. These same people have attempted to improve 
Java's security through the community process--and though often correct, 
diligent, friendly, and well-intentioned, their patience has often been tested 
to or beyond the breaking point: those building the platforms and frameworks 
simply aren't listening that well yet. That is very sad.

One thing I've seen a lot of is organizations assessing, testing, hardening, 
documenting, and internally distributing their own versions of popular Java EE 
toolkits (the "secure struts" phenomenon). I've seen some organizations give 
their developers training and write SAST rules to automatically verify correct 
use of such toolkits. I like this idea a hell of a lot as an alternative to an 
ESAPI-like approach. Why? A few reasons: 

1) Popularity - these toolkits appeal to developers: their interfaces have been 
"voted on" by their adopting user population--not conceived and lamented 
principally by security folk. No one forces developers to go from Struts to 
Spring they do it because it saves them time, makes their app faster, or some 
combination of important factors.

2) Changes App Infrastructure - MVC frameworks, especially, make up the 
scaffolding (hence the name 'Struts') of an application. MVC code often touches 
user input before developer's see it and gets the last chance to encode output 
before a channel (user or otherwise) receives it. Focusing on an application's 
scaffolding allows in some cases, a best-chance of touching all input/out and 
true invisibility relative to developer generated code. Often, its 
configuration is declarative in nature as well--keeping security from 
cluttering up the Java code. Note that this approach is fundamentally different 
from Firewalls and some dynamic patching because it's "in the app" (an argument 
made recently by others in the blogosphere).  

3) Top-to-Bottom Secure by Default - Declarative secure-by-default 
configuration of the hardened toolkit allows for securing those data flows that 
never make it out of the scaffolding into the app. If an organization wrote 
their own toolkit-unware security API, they'd have to not only assure their 
developers call it each-and-every place their it's needed but they'd also need 
to crack open the toolkits and make sure THEY call it too. Most of the time, 
one actively wants to avoid even having this visibility let along maintenance 
problem: it's a major headache.   

and, most importantly,

4) Less Integration points - Developers are already going to have to integrate 
against a MVC framework, so why force them to integrate against YA 
(yet-another) API? The MVC frameworks already contend with things like session 
management, input filtering, output-encoding, and authentication. Why not 
augment/improve that existing idiom rather than force developers to use it and 
an external security API?

The ESAPI team has plenty of responses to the last question... not the least of 
which is "...'cause [framework XXX] sucks." Fair. Out of the box, they often 
do. Fair, [framework team XXX] probably isn't listening to us security guys 
either. 

If you're an ESAPI shop--good. Careful adoption of a security API can help your 
security posture. Please remember to validate that the API (if you sucked in an 
external one rather than writing it) applies to your applications' threat model 
and ticks off all the elements of your security policy. Because, having hooked 
it into their apps, teams are going to want a fair amount of exoneration from 
normal processes (Some of which is OK, but a lot can be dangerous). Second, 
please make sure it's actually secure--it will be a fulcrum of your security 
controls' effectiveness. Make sure that assessment program proves your 
developers used it correctly, consistently, and thoroughly throughout their 
apps. What do I tell you about ESAPI and your MVC frameworks (Point #3 from 
above)? -sigh- That's a longer discussion. And, by all means, don't think you 
can let your guard down on your pen-testing. Is it a silver bullet? No. 

Is ESAPI the only approach? No. I submit that it's -A- way. I hope this email 
outlines that effectively. And viewed from a knowledgeable but separate 
perspective: the ESAPI approach has pluses and minuses just like all the 
others. 
 
----
John Steven
Senior Director; Advanced Technology Consulting
Desk: 703.404.9293 x1204 Cell: 703.727.4034
Key fingerprint = 4772 F7F3 1019 4668 62AD  94B0 AE7F EEF4 62D5 F908

Blog: http://www.cigital.com/justiceleague
Papers: http://www.cigital.com/papers/jsteven
http://www.cigital.com
Software Confidence. Achieved.
 
(*1) http://bsi-mm.com/ssf/intelligence/sfd/?s=sfd1.1#sfd1.1
(*2) During the AppSecDC summit, Jeff indicated the ESAPI project would later 
pilot SAMM but the global projects committee indicated that getting OWASP 
projects to follow some secure development touchpoints is too 
onerous/impossible. Dinis, I'll note is a huge proponent of adherence.


On Jan 6, 2010, at 4:36 PM, James Manico wrote:

> Hello Matt,
> 
> Java EE still has NO support for escaping and lots of other important 
> security areas. You need something like OWASP ESAPI to make a secure app even 
> remotely possible. I was once a Sun guy, and I'm very fond of Java and Sun. 
> But JavaEE 6 does very little to raise the bar when it comes to Application 
> Security.
> 
> - Jim
> 
> On Tue, Jan 5, 2010 at 3:30 PM, Matt Parsons <mparsons1...@gmail.com> wrote:
> >From what I read it appears that this Java EE 6 could be a few rule
> changers.   It looks like to me, java is checking for authorization and
> authentication with this new framework.   If that is the case, I think that
> static code analyzers could change their rule sets to check what normally is
> a manual process in the code review of authentication and authorization.
> Am I correct on my assumption?
> 
> Thanks,
> Matt
> 
> 
> Matt Parsons, MSM, CISSP
> 315-559-3588 Blackberry
> 817-294-3789 Home office
> mailto:mparsons1...@gmail.com
> http://www.parsonsisconsulting.com
> http://www.o2-ounceopen.com/o2-power-users/
> http://www.linkedin.com/in/parsonsconsulting
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: sc-l-boun...@securecoding.org [mailto:sc-l-boun...@securecoding.org]
> On Behalf Of Kenneth Van Wyk
> Sent: Tuesday, January 05, 2010 8:59 AM
> To: Secure Coding
> Subject: [SC-L] Ramesh Nagappan Blog : Java EE 6: Web Application Security
> made simple ! | Core Security Patterns Weblog
> 
> Happy new year SC-Lers.
> 
> FYI, interesting blog post on some of the new security features in Java EE
> 6, by Ramesh Nagappan.  Worth reading for all you Java folk, IMHO.
> 
> http://www.coresecuritypatterns.com/blogs/?p=1622
> 
> 
> Cheers,
> 
> Ken
> 
> -----
> Kenneth R. van Wyk
> SC-L Moderator
> 
> 
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L@securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
> SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
> as a free, non-commercial service to the software security community.
> _______________________________________________
> 
> 
> 
> -- 
> -- 
> Jim Manico, Application Security Architect
> jim.man...@aspectsecurity.com | j...@manico.net
> (301) 604-4882 (work)
> (808) 652-3805 (cell)
> 
> Aspect Security™
> Securing your applications at the source
> http://www.aspectsecurity.com
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L@securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
> SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
> as a free, non-commercial service to the software security community.
> _______________________________________________



Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
_______________________________________________

Reply via email to