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