My view is that the key to make this work is to create the ESTAPI, which is the Enterprise Security <b>Testing</b> API<div><br></div><div>This way we would have (for every language):</div><div><ul><li><b>ESAPI Interfaces</b> - which describe the functionality that each security control should have</li>
<li><b>ESTAPI</b> - Unit Tests that check the behaviour of the security controls</li><li><b>ESAPI Reference Implementation(s) </b>- Which are (wherever possible) 'production ready' versions of those security controls (and in most cases a one-to-one mapping to the ESAPI Interfaces)</li>
<li><b>Framework XYZ ESAPI 'connectors'</b> - Which wrap (or expose) the security controls defined in the ESAPI Interfaces in Framework XYZ</li></ul><div>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)</div>
<div><br></div><div>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.</div>
<div><br></div><div>And hey, if the Framework developers decide NOT to implement a particular security control, that is fine too. </div><div><br></div><div>BUT! </div><div><br></div><div>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 :) )</div>
<div><br></div><div>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: <b>An 'ESAPI compliant app'</b> (which btw is a term we still have to agree what exactly means),<b> is an app that is providing explicit information about where they (the developers) think their (the app) security controls are located</b>.</div>
<div><br></div><div>In another works, via the ESAPI Interfaces (and the ESTAPI tests) the developers are actually telling us (the security consultants): </div><div> a) what they think their application's attack surface is and </div>
<div> b) what is the security behaviour that they have already tested for</div><div><br></div><div>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. </div>
<div><br></div><div>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: </div>
<div> - what it knows (security vulnerabilities) and (as important) </div><div> - what it doesn't know / understand <br>(ok there is a lot more that these tools will provide us (for example ESTAPI tests) but that is a topic for another post)</div>
<div><br></div><div>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'.</div>
<div><br></div><div>Dinis Cruz</div><br><div class="gmail_quote">2010/1/12 Jim Manico <span dir="ltr"><<a href="mailto:jim.manico@owasp.org">jim.manico@owasp.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div bgcolor="#ffffff" text="#000000">
Very well said.<br>
<br>
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.<br>
<br>
This is Dinis' idea, but I'm starting to see the light.<br><font color="#888888">
<br>
- Jim</font><div><div></div><div class="h5"><br>
<br>
<br>
<br>
<br>
<blockquote type="cite">
<div>An FYI from personal experience, be extra careful with the
dependencies, particularly if you develop on an appserver that
optimized for debug and production.</div>
<div> </div>
<div>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</div>
<div> </div>
<div><br>
</div>
<div class="gmail_quote">On Tue, Jan 12, 2010 at 6:54 AM, Jim Manico <span dir="ltr"><<a href="mailto:jim.manico@owasp.org" target="_blank">jim.manico@owasp.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0px 0px 0px 0.8ex;padding-left:1ex">
<div text="#000000" bgcolor="#ffffff">You know Dinis, when I first
read your email I was bit offended. Same with much of John Stevens'
email. <br>
<div><br>
But you know? You are trying to help us. These kinds of pragmatic
questions need to be answered.<br>
<br>
So here goes.<br>
<br>
</div>
<div>
<blockquote type="cite"><span style="font-size:13px;font-family:arial,sans-serif;border-collapse:collapse">
<div>Following the recent thread on Java 6 security and ESAPI, I
just would like to ask the following clarifications: </div>
<div><br>
</div>
<div>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?</div>
</span></blockquote>
<br>
</div>
<div>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. <br>
<br>
</div>
<blockquote type="cite"><span style="font-size:13px;font-family:arial,sans-serif;border-collapse:collapse">
<div><br>
</div>
<div>
<div>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<font face="arial, helvetica, sans-serif"><span style="font-size:small"> to be added, supported and maintained? (for
example on the '</span></font><span style="line-height:19px"><b><font face="arial, helvetica, sans-serif"><span style="font-size:small">Dependencies</span></font><span style="font-weight:normal"><font face="arial, helvetica, sans-serif"><span style="font-size:small">' section of the</span></font></span><span style="font-weight:normal;line-height:normal"><font face="arial, helvetica, sans-serif"><span style="font-size:small"> </span></font><a style="color:rgb(42, 93, 176)" href="http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Java_EE" target="_blank"><font face="arial, helvetica, sans-serif"><span style="font-size:small">ESAPI Java EE</span></font></a><font face="arial, helvetica, sans-serif"><span style="font-size:small"> page
(i.e. Tab) it seems to imply that there are other *.jars needed)</span></font></span></b></span></div>
</div>
</span></blockquote>
<br>
<div>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:<br>
<br>
</div>
(from <a href="http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Java_EE" target="_blank">http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Java_EE</a>)
<div><br>
<br>
<i>There are no dependencies on the ESAPI <b>interfaces</b> 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. <u><b>This list may not
be totally complete.</b></u> </i> </div>
<ul>
<li><i>DefaultAccessController needs… </i>
<ul>
<li><i>Commons-Configuration 1.5 </i></li>
</ul>
</li>
</ul>
<ul>
<li><i>DefaultValidator needs… </i>
<ul>
<div>
<li><i>AntiSamy 1.2 (there may be a few transitive
dependencies here) </i></li>
</div>
<li><i>NekoHTML 0.9.5 </i></li>
<li><i>Xerces 2.9.1 </i></li>
</ul>
</li>
</ul>
<ul>
<li><i>Log4J Logger needs… </i>
<ul>
<li><i>Log4j 1.2.12 </i></li>
</ul>
</li>
</ul>
<ul>
<li><i>DefaultHTTPUtilities needs… </i>
<ul>
<li><i>Commons-FileUpload 1.2 </i></li>
</ul>
</li>
</ul>
<ul>
<li><i>WAF needs </i>
<ul>
<div>
<li><i>XOM 1.0 (there may be a few transitive dependencies
here) </i></li>
</div>
<li><i>Commons-FileUpload 1.2 </i></li>
</ul>
</li>
</ul>
<div><br>
<blockquote type="cite"><span style="font-size:13px;font-family:arial,sans-serif;border-collapse:collapse">
<div><span style="line-height:19px"><b><span style="font-weight:normal;line-height:normal"><font face="arial, helvetica, sans-serif"><span style="font-size:small"><br>
</span></font></span></b></span></div>
<div><font face="arial, helvetica, sans-serif"><span style="font-size:small">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 <a href="http://www.owasp.org/images/8/81/Esapi-datasheet.pdf" target="_blank">Introduction to ESAPI pdf)</a></span></font></div>
</span></blockquote>
<br>
</div>
<div>Detailed from a marketing perspective? :) The best
technical information is our Javadoc pages at <a href="http://owasp-esapi-java.googlecode.com/svn/trunk_doc/2.0-rc4/index.html" target="_blank">http://owasp-esapi-java.googlecode.com/svn/trunk_doc/2.0-rc4/index.html</a>
which 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. <br>
<span style="font-size:13px;font-family:arial,sans-serif;border-collapse:collapse"><font face="arial, helvetica, sans-serif"><span style="font-size:small"><br>
</span></font></span></div>
<div>
<blockquote type="cite"><span style="font-size:13px;font-family:arial,sans-serif;border-collapse:collapse">
<div><span style="line-height:19px"><b><span style="font-weight:normal;line-height:normal"><font face="arial, helvetica, sans-serif"><span style="font-size:small">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)<span style="font-size:13px;line-height:19px;font-family:arial,sans-serif"><b><span style="font-weight:normal;line-height:normal"><font face="arial, helvetica, sans-serif"><span style="font-size:small"> <br>
</span></font></span></b></span></span></font></span></b></span></div>
</span></blockquote>
</div>
<div>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.<br>
</div>
<blockquote type="cite"><span style="font-size:13px;font-family:arial,sans-serif;border-collapse:collapse">
<div><span style="line-height:19px"><b><span style="font-weight:normal;line-height:normal"><font face="arial, helvetica, sans-serif"><span style="font-size:small"><br>
</span></font></span></b></span></div>
<div>
<div><span style="line-height:19px"><b><span style="font-weight:normal;line-height:normal"><font face="arial, helvetica, sans-serif"><span style="font-size:small">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?)</span></font></span></b></span></div>
</div>
</span></blockquote>
I personally grade the reference 2.0 implementation as follows:<br>
<br>
<span style="font-size:13px;font-family:arial,sans-serif;border-collapse:collapse"><font face="arial, helvetica, sans-serif"><span style="font-size:small">
<div>1) Authentication C (Needs deeper enterprise
integration)<br>
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)<br>
3) Input validation A- (needs better messaging and
internationalization (thanks Sklarew for making us think in the right
direction about this)<br>
4) Output encoding/escaping A (Go Jeff, my only A. :) We do need a
performance tuning pass (easy) and DOM XSS encoding functions)<br>
5) Cryptography A- (Great work Kevin, this is a huge huge improvement
from 1.4)<br>
</div>
6) Error handling and logging B+ (Nice work on designing this from
Wichers)<br>
7) Communication security ? <br>
<div>8) HTTP security B- (Great utilities! I'd like to
see some of these decoupled a bit more)<br>
9) Security configuration ?<br>
<br>
Digging deeper....<br>
<br>
</div>
</span></font></span>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. <a href="http://owasp-esapi-java.googlecode.com/svn/trunk/documentation/esapi4java-core-2.0-readme-crypto-changes.html" target="_blank">http://owasp-esapi-java.googlecode.com/svn/trunk/documentation/esapi4java-core-2.0-readme-crypto-changes.html</a>
. 2.0 is going to be a very big milestone; I'm pretty stoked about what
I'm seeing from the team.
<div><br>
<br>
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. <br>
<br>
</div>
<blockquote type="cite"><span style="font-size:13px;font-family:arial,sans-serif;border-collapse:collapse">
<div><span style="line-height:19px"><b><span style="font-weight:normal;line-height:normal"><font face="arial, helvetica, sans-serif"><span style="font-size:small"><br>
</span></font></span></b></span></div>
<div>
<div><span style="line-height:19px"><b><span style="font-weight:normal;line-height:normal"><font face="arial, helvetica, sans-serif"><span style="font-size:small">6)
Are there commercial (i.e. <span style="font-size:13px;line-height:19px;font-family:arial,sans-serif"><b><span style="font-weight:normal;line-height:normal"><font face="arial, helvetica, sans-serif"><span style="font-size:small">paid) <span style="font-size:13px;line-height:19px;font-family:arial,sans-serif"><b><span style="font-weight:normal;line-height:normal"><font face="arial, helvetica, sans-serif"><span style="font-size:small">support
services available for the companies who want to add ESAPI.jar to they
application?</span></font></span></b></span></span></font></span></b></span></span></font></span></b></span></div>
</div>
</span></blockquote>
<br>
<div>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.<br>
</div>
<blockquote type="cite"><span style="font-size:13px;font-family:arial,sans-serif;border-collapse:collapse">
<div><span style="line-height:19px"><b><span style="font-weight:normal;line-height:normal"><font face="arial, helvetica, sans-serif"><span style="font-size:small"><br>
</span></font></span></b></span></div>
<div>
<div><font face="arial, helvetica, sans-serif"><span style="font-size:small">7) What is the version of ESAPI.jar that we
should recommend? the version 1.4 (which lo</span></font>oks like a
stable release) or the version 2.0 rc4 (which looks like it is a
Release Candidate)</div>
</div>
</span></blockquote>
ESAPI 1.4.1 is <b>very </b>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.<br>
<blockquote type="cite"><span style="font-size:13px;font-family:arial,sans-serif;border-collapse:collapse">
<div><br>
</div>
<div>
<div>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)</div>
</div>
</span></blockquote>
Yea, Docs. We need more docs. Boberski has done incredible work in this
area.<br>
<blockquote type="cite"><span style="font-size:13px;font-family:arial,sans-serif;border-collapse:collapse">
<div><br>
</div>
<div>
<div>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)</div>
</div>
</span></blockquote>
Under "users and adopters" <a href="http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Contributors.2FUsers" target="_blank">http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Contributors.2FUsers</a>
<div><br>
<blockquote type="cite"><span style="font-size:13px;font-family:arial,sans-serif;border-collapse:collapse">
<div><br>
</div>
<div>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?</div>
</span></blockquote>
</div>
Yes and see #8 sentence 2.<br>
<blockquote type="cite"><span style="font-size:13px;font-family:arial,sans-serif;border-collapse:collapse">
<div><br>
</div>
<div>
<div>11) <i><b><span style="font-weight:normal;font-style:normal">when Jim says <i>"... you
can build a new secure app without an ESAPI. But libs like OWASP ESAPI
will get you there faster and cheaper....", </i></span> </b><span style="font-style:normal">do we have peer-reviewed data that suports
this claim? <br>
</span></i></div>
</div>
</span></blockquote>
<div>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. <br>
</div>
<blockquote type="cite"><span style="font-size:13px;font-family:arial,sans-serif;border-collapse:collapse">
<div><i><span style="font-style:normal"><br>
</span></i></div>
<div>
<div><i><span style="font-style:normal">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'?</span></i></div>
</div>
</span></blockquote>
See #8 sentence 2.
<div>
<blockquote type="cite"><span style="font-size:13px;font-family:arial,sans-serif;border-collapse:collapse">
<div><i><span style="font-style:normal"><br>
</span></i></div>
<div><i><span style="font-style:normal">13) What about the
current implementations of ESAPI for the other languages. Are we
also recommending their use?</span></i></div>
</span></blockquote>
</div>
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.
<div><br>
<blockquote type="cite"><span style="font-size:13px;font-family:arial,sans-serif;border-collapse:collapse">
<div><i><span style="font-style:normal"><br>
</span></i></div>
<div><i><span style="font-style:normal">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...)</span></i></div>
</span></blockquote>
<br>
</div>
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. <a href="http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet" target="_blank">http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet</a>
<br>
<blockquote type="cite"><span style="font-size:13px;font-family:arial,sans-serif;border-collapse:collapse">
<div><i><span style="font-style:normal"><br>
</span></i></div>
<div><i><span style="font-style:normal">Thanks</span></i></div>
<div><i><span style="font-style:normal"><br>
</span></i></div>
<div><i><span style="font-style:normal">Dinis Cruz</span></i></div>
</span></blockquote>
<i><br>
</i>
<div>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.<br>
<br>
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).<br>
<br>
Another 18 hour day - I need sleep. :)<br>
<br>
Regards,<br>
- Jim<br>
</div>
</div>
<br>
_______________________________________________<br>
Esapi-dev mailing list<br>
<a href="mailto:Esapi-dev@lists.owasp.org" target="_blank">Esapi-dev@lists.owasp.org</a><br>
<a href="https://lists.owasp.org/mailman/listinfo/esapi-dev" target="_blank">https://lists.owasp.org/mailman/listinfo/esapi-dev</a><br>
<br>
</blockquote>
</div>
<br>
</blockquote>
<br>
<br>
</div></div><div class="im"><pre cols="72">--
Jim Manico
OWASP Podcast Host/Producer
<a href="http://www.manico.net" target="_blank">http://www.manico.net</a></pre>
</div></div>
</blockquote></div><br></div>