Dinis Cruz wrote:
Following the recent thread on Java 6 security and ESAPI, I just would like
to ask the following clarifications:
Dinis... all really good questions. I'll comment on the ones I have some
some sense of and feel qualified to answer and punt on the others. (I'm
also going to delete those I'm not going to attempt to answer to shorten
the response.)
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'm not aware of an *official* recommendation OWASP intends to make, but if they
do, I doubt it will be until sometime after ESAPI 2.0 is officially released.
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
EEhttp://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)*
To a large degree, what jars are needed depends on what ESAPI security controls
are used by your application. (That what the Dependencies section on the URL
you referenced tries to clarify.)
Almost all the security controls use ESAPI logging which can be configured to
use either the Log4j or (Sun) Java logging. Log4j is the default, so if that is
used obviously a log4j jar is required.
All of the dependency jars are bundled with the ESAPI zip file, but which ones
you will actually needs depends on what ESAPI security controls are needed.
*
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
Most of the detailed information--at least to the degree that we would like
it--is not yet completed. (I'm not even sure all the docs that are planned
have people to work on them yet. Some are awaiting developers to finish up
their stuff to pitch in and contribute. Mike Boberski is in charge of the
ESAPI documentation. He can fill you in on its status.)
*4) ...snip...
No comment.
*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?)*
My only comment on that is to *NOT* use the symmetric encryption in ESAPI 1.4.
It has lots of problems. One would be better off using encryption in the 2.0
release candidates (but even that is is a minor state of flux).
*6) ...snip...
No comment.
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)
Version 2.0 has some new features (e.g., WAF) that were not available in 1.4.
It also attempts to address some things that were broken in 2.0 (e.g., see
response to #4). Ultimately this is probably one of those it depends answers.
I'll let Jim or Jeff provide a more official answer.
8) - 12) ...snip...
No comment.
*13) What about the current implementations of ESAPI for the other
languages. Are we also recommending their use?*
IMO, doubtful. Most of the other languages are far behind the Java
implementation.
*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...)*
IMO, I think the ideal situation would be if we could get the Spring and Struts,
etc. development communities to integrate their frameworks so that they could
be used with the ESAPI interfaces. (In many of these cases, these
implementations would replace the ESAPI reference implementation.) However,
that is obviously going to take some time. I don't think that the ESAPI
dev team can do it all.
[Note: I am replying to both mailing lists. There may be policies against this.
If so, my apologies. However just wanted to make people aware of this; if they
Reply-All, they will need to be subscribed to both mailing lists from their
sending email address.]
-kevin
--
Kevin W. Wall
The most likely
