[Esapi-user] [Esapi-dev] Recommending ESAPI?

[mike.boberski at gmail.com (Mike Boberski)]

> we start to create standards for how Security Controls should behave [and
basically the rest of the post]

I submit ASVS for your consideration. If one is further concerned about
building blocks in the environment, check out Common Criteria and FIPS
140-2.

Also,

There have also been discussions about creating standardized test suites for
ESAPI implementations to ensure consistent security checks/effects across
ESAPI language implementations, but I don't think that's what you're getting
at.

It's not hard (with respect) to differentiate interfaces from reference
implementations from adapters (customized controls), please see the design
patterns doc I wrote that's posted to the project page. I'm not sure I see
advantages to further rearranging and splitting out the interfaces.

Best,

Mike


On Tue, Jan 12, 2010 at 7:38 PM, Dinis Cruz <dinis.cruz at googlemail.com>wrote:

> My view is that the key to make this work is to create the ESTAPI, which is
> the Enterprise Security *Testing* API
>
> This way we would have (for every language):
>
>    - *ESAPI Interfaces* - which describe the functionality that each
>    security control should have
>    - *ESTAPI* - Unit Tests that check the behaviour of the security
>    controls
>    - *ESAPI Reference Implementation(s) *- Which are (wherever possible)
>    'production ready' versions of those security controls (and  in most cases a
>    one-to-one mapping to the ESAPI Interfaces)
>    - *Framework XYZ ESAPI 'connectors'* - Which wrap (or expose) the
>    security controls defined in the ESAPI Interfaces in Framework XYZ
>
> What I really like about this world, is that we (Application Security
> Consultants) we start to create standards for how Security Controls should
> behave. and (as important) are able to work with the Framework developers
> without they felling that ESAPI is a 'competitor' to they Framework. After
> all, the way we will really change the market is when the Frameworks used by
> the majority of developers adopt ESAPI (or its principles)
>
> Of course that the Framework developers are more than welcomed to grab
> large parts (or even all) of the code provided by the ESAPI reference
> implementation(s). But the key is that they (the framework developers) must:
> a) take ownership of the code and b) respect the ESAPI Interfaces.
>
> And hey, if the Framework developers decide NOT to implement a particular
> security control, that is fine too.
>
> BUT!
>
> I would at least expect them to provide detailed information why they made
> that decision and why they chose NOT to implement or support it (which would
> allow us (Security community) to respectably agree or disagree with their
> choices (hey for some Frameworks, being insecure is a feature :) )
>
> Finally, In addition to all the advantages that we will have when
> frameworks adopt these security controls, there is one that for me is
> probably the MOST important one: *An 'ESAPI compliant app'* (which btw is
> a term we still have to agree what exactly means),* is an app that is
> providing explicit information about where they (the developers) think their
> (the app) security controls are located*.
>
> In another works, via the ESAPI Interfaces (and the ESTAPI tests) the
> developers are actually telling us (the security consultants):
>   a) what they think their application's attack surface is and
>   b) what is the security behaviour that they have already tested for
>
> Of course that they can game the system, which is why we (Security
> Consultants) will still be needed (we will also need to make sure that they
> implemented the security controls properly). But compare that to today's
> (2009) world, were we are lucky to get an up-to-date application diagram and
> a reasonable accurate description of how the application was actually coded
> and behaves.
>
> This would also (finally) give the application security tools (white,
> black, glass, gray, pink, blue) a fighting change to automatically, or
> operator-driven, understand what is going on and report back:
>   - what it knows (security vulnerabilities) and (as important)
>   - what it doesn't know / understand
> (ok there is a lot more that these tools will provide us (for example
> ESTAPI tests) but that is a topic for another post)
>
> So, for me, the key added value of the ESAPI Interfaces, is that it will
> provide us (Security Consultants) a way to understand how the app works
> (from a security point of view) and to be able to finally be able to give
> the clients what they want: Visibility, Assurance and the ability to make
> 'knowledgeable Risk-based decisions'.
>
> Dinis Cruz
>
> 2010/1/12 Jim Manico <jim.manico at owasp.org>
>
> >  Very well said.
> >
> > On this note, I think we may wish to consider formally splitting the
> > interfaces from the reference implementation. We could then build a test
> > framework that's tests those interfaces - so we can verify different
> > implementations of ESAPI. Expand this out in a cross-language way, and we
> > have some serious magic to work with.
> >
> > This is Dinis' idea, but I'm starting to see the light.
> >
> > - Jim
> >
> >
> >
> >
> >
> >
> > An FYI from personal experience, be extra careful with the dependencies,
> > particularly if you develop on an appserver that optimized for debug and
> > production.
> >
> > You may need these libraries even if you are not using the area of the
> > ESAPI RI that uses them.  The -Xverify:none JVM argument changes how the
> > classloader pre-caches some classes, particularly Exceptions.  Despite not
> > needing to use safe file upload capabilities, without that JVM arg is was
> > looking for Exceptions found in the commons-uploads jar
> >
> >
> >
> > On Tue, Jan 12, 2010 at 6:54 AM, Jim Manico <jim.manico at owasp.org> wrote:
> >
> > > You know Dinis, when I first read your email I was bit offended. Same
> > > with much of John Stevens' email.
> > >
> > > But you know? You are trying to help us. These kinds of pragmatic
> > > questions need to be answered.
> > >
> > > So here goes.
> > >
> > >   Following the recent thread on Java 6 security and ESAPI, I just would
> > > like to ask the following clarifications:
> > >
> > >  1) For an existing web application currently using a MVC framework
> > > (like Spring or Struts) are we today (9th Jan 2009) officially
> > > recommending that this web application development team adds OWASP's
> > > ESAPI.jar to the list of 'external' APIs (i.e. libs) they use, support and
> > > maintain?
> > >
> > >
> > >  I can personally attest for ESAPI 2.0 rc4 integration into Struts
> > > 1.3.x, where I've used ESAPI for several years, from the early days. I'm not
> > > deeply familiar with Spring. I would not say this is a trivial exercise, but
> > > it certainly is possible.
> > >
> > >
> > >  2) When adopting the OWASP ESAPI's J2EE implementation, is ESAPI.jar
> > > ALL they need to add? or are there other dependencies (i.e. jars) that also
> > > need to be added, supported and maintained? (for example on the '*
> > > Dependencies' section of the ESAPI Java 
> > > EE<http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Java_EE> page
> > > (i.e. Tab) it seems to imply that there are other *.jars needed)*
> > >
> > >
> > > ESAPI.jar has significant dependencies - something that is a problem, in
> > > general, in the Java world. I'm optimistic about the new Java 7 component
> > > framework - but that is a long way off.  In the meantime:
> > >
> > >  (from
> > > http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Java_EE)
> > >
> > >
> > >
> > > *There are no dependencies on the ESAPI interfaces other than standard
> > > Java EE. However, the reference implementation does have dependencies that
> > > are detailed below. The reference implementation takes advantage of a few
> > > existing libraries. This list may not be totally complete. *
> > >
> > >    - *DefaultAccessController needs? *
> > >       - *Commons-Configuration 1.5 *
> > >
> > >
> > >    - *DefaultValidator needs? *
> > >        - *AntiSamy 1.2 (there may be a few transitive dependencies here)
> > >       *
> > >       - *NekoHTML 0.9.5 *
> > >       - *Xerces 2.9.1 *
> > >
> > >
> > >    - *Log4J Logger needs? *
> > >       - *Log4j 1.2.12 *
> > >
> > >
> > >    - *DefaultHTTPUtilities needs? *
> > >       - *Commons-FileUpload 1.2 *
> > >
> > >
> > >    - *WAF needs *
> > >        - *XOM 1.0 (there may be a few transitive dependencies here) *
> > >       - *Commons-FileUpload 1.2 *
> > >
> > >
> > >  *
> > > *
> > > 3) Where can I find detailed information about each of the 9 Security
> > > Controls that ESAPI.jar currently supports: 1) Authentication, 2) Access
> > > control, 3) Input validation, 4) Output encoding/escaping, 5) Cryptography,
> > > 6) Error handling and logging, 7) Communication security, 8) HTTP security
> > > and 9) Security configuration? (I took this list of controls from the Introduction
> > > to ESAPI pdf) <http://www.owasp.org/images/8/81/Esapi-datasheet.pdf>
> > >
> > >
> > >  Detailed from a marketing perspective? :) The best technical
> > > information is our Javadoc pages at
> > > http://owasp-esapi-java.googlecode.com/svn/trunk_doc/2.0-rc4/index.htmlwhich are not complete, but are fairly 
> > > decent. We have also been very good
> > > about answering questions, fast, on esapi-users and esapi-dev. But you are
> > > right - docs are evolving, but we need more.
> > >
> > >   *4) When adopting EASPI.jar, are we recommending that the developers
> > > should adopt or retrofit their existing code on the areas affected by those
> > > 9 Security Controls? (i.e. code related to: Authentication, Access
> > > control, Input validation, Output encoding/escaping, Cryptography, Error
> > > handling and logging, Communication security, HTTP security and Security
> > > configuration)
> > > *
> > >
> > >  It really depends on the situation. But I get your point - I've seen
> > > the Validator, Encoder, Utils and Error Handling modules used in
> > > retrofitting situations successfully. I'm not so sure about the others.
> > >
> > > *
> > > *
> > >  *5) Should we recommend the adoption of ALL 9 Security Controls? or are
> > > there some controls that are not ready today (9 Jan 2009) for production
> > > environments and should not be recommended? (for example is the
> > > 'Authentication' control as mature as the 'Error handling and logging'
> > > control?)*
> > >
> > > I personally grade the reference 2.0 implementation as follows:
> > >
> > >  1) Authentication   C (Needs deeper enterprise integration)
> > > 2) Access control   B- (This is just a really tough issue, and usually
> > > requires deep application-specific context. Plus we have some good ideas on
> > > the table from Beef that I'd like to consider)
> > > 3) Input validation   A- (needs better messaging and internationalization
> > > (thanks Sklarew for making us think in the right direction about this)
> > > 4) Output encoding/escaping   A (Go Jeff, my only A. :) We do need a
> > > performance tuning pass (easy) and DOM XSS encoding functions)
> > > 5) Cryptography  A- (Great work Kevin, this is a huge huge improvement
> > > from 1.4)
> > >  6) Error handling and logging  B+ (Nice work on designing this from
> > > Wichers)
> > > 7) Communication security ?
> > > 8) HTTP security B- (Great utilities! I'd like to see some of these
> > > decoupled a bit more)
> > > 9) Security configuration ?
> > >
> > > Digging deeper....
> > >
> > >  I personally use almost all of ESAPI. I've written my own Hibernate
> > > Authentication layer - but it's very specific to my data model. It's very
> > > difficult to decouple this from my app and would be difficult to donate it
> > > to the project effectively. Same with access control. My data model is VERY
> > > complex, and donating it without SQL scripts, hibernate configuration, and a
> > > whole lot of other code - is a great challenge. (Not to mention that my
> > > employer owns the code ;) The flat-file authenticator is just a proof of
> > > concept and should never be used in a production environment of any kind,
> > > IMO. The thread-local nature of the authenticator, while I use it and love
> > > it, needs to be reconsidered since other classes, like the loggers, depend
> > > on it. Error handling is fairly solid - and is only a thin layer on top of
> > > known logging methods + security specific messaging. The encoder was handed
> > > down from Gosling himself - given to Jeff - who gifted it to us. :) I want
> > > the encoder to be a hard-coded part of ESAPI. :) The validator and encoder
> > > can be dropped into any project fairly easy. Same with much of the HTTP
> > > Utils. The Encryptor from 1.4 should be avoided, which impacts other
> > > portions of the codebase.
> > > http://owasp-esapi-java.googlecode.com/svn/trunk/documentation/esapi4java-core-2.0-readme-crypto-changes.html
> > > . 2.0 is going to be a very big milestone; I'm pretty stoked about what I'm
> > > seeing from the team.
> > >
> > >
> > > Most importantly, it's easy to use the ESAPI configuration layer to
> > > over-ride any of the reference implementation with your personal
> > > authenticator or access controller (so long as you implement the ESAPI
> > > interfaces), as I have for my projects.
> > >
> > >  *
> > > *
> > >  *6) Are there commercial (i.e. paid) support services available for the
> > > companies who want to add ESAPI.jar to they application?*
> > >
> > >
> > > I hesitate to mention this, and I'm not trying to pimp - but I'm
> > > respectfully answering all of your questions. Aspect offers these services.
> > > I've been working with Jeff on some of those efforts. It's working out well
> > > for Aspects clients, I'd dare say. If someone else wishes to speak up on
> > > this topic, please do. Open.
> > >
> > > *
> > > *
> > >  7) What is the version of ESAPI.jar that we should recommend? the
> > > version 1.4 (which looks like a stable release) or the version 2.0 rc4
> > > (which looks like it is a Release Candidate)
> > >
> > > ESAPI 1.4.1 is *very *far behind 2.0 rc4.  Java 4 is way past end of
> > > lifecycle - but it's still in very wide use, so we plan to back-port all of
> > > ESAPI 2.0 to 1.4. Or at least as much as we can. I'm making some changes
> > > this week and plan on releasing 1.4.2 this week.
> > >
> > >
> > >  8) Where can I find the documentation of where and how ESAPI should be
> > > used? More importantly, where can I find the information of how it CAN NOT
> > > or SHOULD NOT be used (i.e. the cases where even when the EASPI.jar are
> > > used, the application is still vulnerable)
> > >
> > > Yea, Docs. We need more docs. Boberski has done incredible work in this
> > > area.
> > >
> > >
> > >  9) if there list of companies that have currently added ESAPI.jar to
> > > their applications and have deployed it? (i.e. real world usage of EASPI)
> > >
> > > Under "users and adopters"
> > > http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Contributors.2FUsers
> > >
> > >
> > >  10) Has the recommended ESAPI.jar (1.4 or 2.0 rc4) been through a
> > > security review? and if so where can I read its report?
> > >
> > >  Yes and see #8 sentence 2.
> > >
> > >
> > >  11) *when Jim says "... you can build a new secure app without an
> > > ESAPI. But libs like OWASP ESAPI will get you there faster and
> > > cheaper....",  do we have peer-reviewed data that suports this claim?
> > > *
> > >
> > > Nope. I'm shooting from the hip and I consider this as common sense. But
> > > I agree, we REALLY need more assurance evidence that is published on the
> > > wiki - perhaps we should run o2 against the ESAPI codebase for starters. Or
> > > maybe someone can donate code review services and publish that report on our
> > > wiki. I hear you. Assurance, published assurance, is fundamental.
> > >
> > > *
> > > *
> > >  *12) Is there a roadmap or how-to for companies that wish to adopt
> > > ESAPI.jar on an a) new application or b) existing real-world application'?
> > > *
> > >
> > > See #8 sentence 2.
> > >
> > > *
> > > *
> > > *13) What about the current implementations of ESAPI for the other
> > > languages. Are we also recommending their use?*
> > >
> > >  Most are beta or alpha - with sparkles of 1.0. But I'd love to hear the
> > > other language leaders chime in here. I focus on the Java version of ESAPI.
> > >
> > >  *
> > > *
> > > *14) If a development team decides to use (for example) Spring and ESAPI
> > > together in their (new or existing) application, what are the recommended
> > > 'parts' from each of those APIs (Spring and EASPI) that the developers
> > > should be using? (for example: a) use Encoding from ESAPI, b) use
> > > Authentication from Spring, c) use Authorization from ESAPI, d) use Error
> > > Handling from Spring, e) use Logging from ESAPI, etc...)*
> > >
> > >
> > >  I just don't know how to answer this question. I think for starters, the
> > > completeness of our encoder helps stop XSS cold in a way that is a bit
> > > better than the frameworks. And Jeff authorer a great cheat sheet to go
> > > alongside it.
> > > http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet
> > >
> > > *
> > > *
> > > *Thanks*
> > > *
> > > *
> > > *Dinis Cruz*
> > >
> > > *
> > > *
> > > I'm not going to shy away from these emails any longer. Is this all you
> > > got, Dinis? John Steven? Bring it on, I'll do my best to answer as honestly
> > > as I can.
> > >
> > > But let me tell you, Dinis. I would not consider building any Java app
> > > without ESAPI. :) (please note the "I" statement - I've been deep in the
> > > code for years, I'm not saying its easy - it requires significant investment
> > > of time to use all of ESAPI as it stands today).
> > >
> > > Another 18 hour day - I need sleep. :)
> > >
> > > Regards,
> > > - Jim
> > >
> > > _______________________________________________
> > > Esapi-dev mailing list
> > > Esapi-dev at lists.owasp.org
> > > https://lists.owasp.org/mailman/listinfo/esapi-dev
> >
> >
> > --
> > Jim Manico
> > OWASP Podcast Host/Producerhttp://www.manico.net
>
> _______________________________________________
> Esapi-user mailing list
> Esapi-user at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/esapi-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100112/710664a2/attachment-0001.htm>