Secure Coding mailing list archives

Previous By Date Next
Previous By Thread Next

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

From: jsteven at cigital.com (John Steven)
Date: Mon, 11 Jan 2010 20:42:22 -0500
All,

Much has been said offline on this thread and so I'm going to say only things included herein to hopefully conclude my 
involvement in the SC-L topic. I hope I've provided useful direction for considering ESAPI adoption in this forum. 

For those interested, I'll be continuing the conversation with the appropriate folk within the ESAPI project on their 
lists. At least two OWASP board members see similar opportunities for maturing ESAPI and I'll confine that discussion 
in the audience that can be most productive with it.

See intermittent comments.

On Jan 8, 2010, at 12:57 AM, Jim Manico wrote:


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.


No, I don't think the frameworks will be "Secure". I don't believe apps will be "Secured" solely within the application 
code either. Both layers possess a non-negligable percentage of the executing (and vulnerable) code and each layer's 
abstractions have failed to isolate and provide security for the other layer. (IN)Security will continue to behave like 
the emergent property it is: and a focus on only part of the application's code base will ultimately fail to secure it 
(*1). 

Consider an 'application' as the whole stack of things when deployed. Software-centric application security 
practitioners (like myself, say) are often all-too-keen to think problems can be solved in the code written by that top 
crust of application developers or disregard benefits of WAFs and dynamic patching. Others over-rely on pen-testing an 
network security controls, while others focus on discovery tools, IDS/IPS, host hardening, and incident response.  

This list's moderator might tell you securing an app demands considering all the layers and getting all the right roles 
discussing the best solution to uncovered problems. We all need to keep each other honest in this pursuit because each 
of us will gravitate to a particular layer of the stack. For my own part, I'm hoping to lean on Mr. Van Wyk and Mr. 
Tomhave for that very service for the NoVA OWASP chapter: keep me honest on this one ;-)


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.


On the ESAPI Users mailing list, Wililams said the following(*2):


It's always best if developers can work within their framework. The
ESAPI project is trying to build some foundational security controls so
that developers don't have to keep remaking the same mistakes over and
over.  If your framework already provides a control already, great.  If
your framework wants to use ESAPI and hide it from the developer, great.
In some cases, the framework might want to expose ESAPI, and that's fine
too.



I mentioned an adoption guide as advice to the ESAPI team. Architects within each organization will have to convince 
themselves that ESAPIs strengths and posture match their threat model and then lay out how they're going to want 
developers to interface with its security controls. Coverage of every framework is too much to ask but every 
organization has 2-3 commonly used MVC frameworks: that's where to start. 

It's wonderful when you can use the framework's declarative description to call out to things (like validators). Again, 
see Williams:


If you want to use Struts Validators, for example, you can write a custom validator
that delegates to an ESAPI validator.


Personally, I prefer the Struts abstraction (as it hides validation from developers as a matter of design... albeit 
abstraction is where Struts stops :-P)  You get validated input without the need to clutter the code (see my original 
email). I recommend this approach as the de facto integration strategy even for non-struts apps (though it requires 
some scaffolding).  But, if you can't pull this off, where does that leave us?

Manico nearly suggests(*3) another way to get the next lightest level of 'light touch' on the code when he discussed 
the notion of a cross-cutting concern. Using AspectJ you may be able to weave in such controls and not have to worry 
about hitting every entry point manually. If you're integrating an ESAPI -into- your framework code this approach might 
suit you: input validation aspects could be woven into application and framework code alike as part of a build / deploy 
process. While this approach has its own limitations I've been using it in the form of my own custom meta-class 
annotations when I can't bake the abstraction in tightly under the hood (for a Python object) to assure non-security 
properties (singleton pattern, monitor-lock, and others) are upheld in a very syntactically agreeable manner(*4). 

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

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. Developers simply won't be able to reach the total 
consistency required for robust defense in a large existing application. 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.  
 

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.


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

Cheers all,
----
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) This same argument scales down into the platform further: Java EE core, underlying OS / hypervisor... etc. 

(*2) Message dated: Jan 2010 00:04:49, ESAPI-Users Mailing list

(*3) Quoting Manico:

I've used regular expression multi-file-search-and-replace tricks across many million LOC applications


In the case of (*3), I prefer AOP or SA to RegExp because of the provided type-safety of the two approaches and the 
option to log transforms. Though, for some cut-points, RegExp may be sufficient to accurately 'lock in' a cut-point.

(*4) Unlike the purely struts-based approach though, developers have to remember the annotation and change does 
necessitate recompilation and redeployment (be it Python, Java or .NET).

(*5) These areas appear to have received the lion share of attention to date (rightfully so, and to great avail) 


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




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4359 bytes
Desc: not available
URL: <http://krvw.com/pipermail/sc-l/attachments/20100111/d2d8e9f6/attachment-0001.bin>
Previous By Date Next
Previous By Thread Next

Current thread: