[SC-L] Ramesh Nagappan Blog : Java EE 6: Web Application Security made simple ! | Core Security Patterns Weblog
Jim Manico
jim at manico.net
Fri Jan 8 00:57:50 EST 2010
John,
Do you think we will reach a point where toolkits/frameworks will
become so powerful that a developer will no longer require application
security knowledge? I say no. Not now, not in 10 or 20 years. I
encourage you to read my notes again. My comment was:
>>>> You need something like OWASP ESAPI to make a secure app even
>>>> remotely possible
I think secure frameworks with built-in developer controls fits that
very general statement, even though you clearly disagree.
I'm trying to get to a deeper issue here. I feel we need to empower
developers with knowledge and the right APIs, and this thread includes
my opinion that Java 6EE does little to move us in that direction. Of
course, lower risk apps can sometimes tollerate less assurance. Of
course legacy apps are much more difficult to secure. Ramming ESAPI
into an existing app is often non-trivial, especially since we are
still a young project and indeed need more documentation. In fact,
ESAPI is no AppSec Jesus. I tried to make that clear below:
>> An ESAPI is no silver bullet, there is no such thing as that in
>> AppSec. But it will help build secure apps.
Adressing you other point, I've used regular expression multi-file-
search-and-replace tricks across many million LOC applications to help
lock down certain vulnerability classes, especially XSS. It's still a
non trivial technique and requires significant regression testing, but
it is possible in some cases for some security areas.
Last, if we make frameworks overly secure, we start to limit
capabilities and innovation. We need to give developers some rope -
and if they get some AppSec training and 50 or so functions specific
to security controls - they might not hang themselves! :)
And this is not just a wild idea, I'm lucky to witness some of the
largest institutions on the planet sucessfully implement ESAPI in the
real world.
And sure, you can build a new secure app without an ESAPI. But libs
like OWASP ESAPI will get you there faster and cheaper.
- Manico
On Jan 7, 2010, at 1:02 PM, John Steven <jsteven at cigital.com> wrote:
> Jim,
>
> Yours was the predicted response. The ref-impl. to API side-step
> does not fix the flaw in the argument though.
>
> No, you do not need "A" ESAPI to build secure apps.
>
> Please re-read my email carefully.
>
> Alternatives:
> 1) Some organizations adopt OWASP ESAPI's ref-impl.
> 2) Others build their own do agree and see the value; yes
>
> #1 and #2 agree with your position.
>
> 3) Some secure their toolkits (again, "a la secure struts")
>
> Indicating such a "secure struts" is an organization's ESAPI
> perverts the ESAPI concept far too greatly to pass muster. Indeed,
> were it to, it would violate properties 3 and 4 (and very likely 2)
> within my previous email's advantage list.
>
> Mr. Boberski, you too need to re-read my email. I advise you
> strongly not to keep saying that ESAPI is "like PK-enabling" an APP.
> I don't think many people got a good feeling about how much they
> spent on, or how effective their PKI implementation was ;-). Please
> consider how you'd ESAPI-enable the millions of lines of underlying
> framework code beneath the app.
>
> 4) Policy + Standards, buttressed with a robust assurance program
>
> Some organizations have sufficiently different threat models and
> deployment scenarios within their 'four walls' that they opt for
> specifying an overarching policy and checking each sub-
> organization's compliance--commensurate with their risk tolerance
> and each app deployment's threat model. Each sub-organization may-or-
> may-not choose to leverage items one and two from this list. I
> doubt, however, you'd argue that more formal methods of verification
> don't suffice to perform 'as well' as ESAPI in securing an app (BTW,
> I have seen commercial implementations opt for such verification as
> an alternative to a security toolkit approach). Indeed, an single
> security API would likely prove a disservice if crammed down the
> throats of sub-organizations that differ too greatly.
>
> At best, the implicit "ESAPI or the highway" campaign slogan
> applies to only 50% of the alternatives I've listed. And since the
> ESAPI project doesn't have documented and publicly available good,
> specific, actionable requirements, mis-use cases, or a threat model
> from which it's working, the OWASP ESAPI project doesn't do as much
> as it could for the #2 option above.
>
> Jim, Mike, I see your posts all-througout the the blog-o-sphere and
> mailing lists. Two-line posts demanding people adopt ESAPI or forgo
> all hope can off-put. It conjures close-minded religion to me. Rather:
>
> * Consider all four of the options above, one might be better than
> OWASP ESAPI within the context of the post
> * Consider my paragraph following Point #4. Create:
>
> * An ESAPI mis-use case guide, back out security policy it
> manifests,
> or requirements it implements (and don't point me to the unit
> tests--I've read them)
> * Document an ESAPI threat model (For which apps will developers
> have
> their expectations met adopting ESAPI? Which won't?)
> * A document describing experiment results: before and after ESAPI:
> how many results does a pen-test find?, 'Code review?
> * Write an adoption guide. Apps are only created in a green-field
> once. Then they live in maintenance forever. How do you apply
> ESAPI to a real-world app already in production without risk/
> regression?
>
> * Generate an argument as to why ESAPI beats these alternatives. Is
> it cost? Speed-to-market? What?
> * Finally, realize that it's OK that there's more than one way to do
> things. Revel in it. It's what makes software an exciting field.
>
> In the meantime, rest assured that those of us out there that have
> looked get that ESAPI can be a good thing.
>
> ----
> 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.
>
> On Jan 7, 2010, at 10:56 AM, Jim Manico wrote:
>
>> John,
>>
>> You do not need OWASP ESAPI to secure an app. But you need "A" ESAPI
>> for your organization in order to build secure Apps, in my opinion.
>> OWASP ESAPI may help you get started down that path.
>>
>> An ESAPI is no silver bullet, there is no such thing as that in
>> AppSec. But it will help build secure apps.
>>
>> Jim Manico
>>
>> On Jan 6, 2010, at 6:20 PM, John Steven <jsteven at cigital.com> wrote:
>>
>>> 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
>>>> <mparsons1980 at 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:mparsons1980 at 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-bounces at securecoding.org [mailto:sc-l-
>>>> bounces at 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 at 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.manico at aspectsecurity.com | jim at 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 at 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 at 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 at 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.
> _______________________________________________
More information about the SC-L
mailing list