[Owasp-appsensor-project] Fwd: AppSensor & ESAPI
jtmelton at gmail.com
Mon Nov 1 13:08:32 EDT 2010
Not sure I agree with #1 - not sure why we need to stop using ESAPI. I'm
not sure how maven deals w/ circular dependencies, but ESAPI's interaction
w/ appsensor for the most part would be through the intrusion detector
mechanism ... ESAPI.intrusionDetector().addException(this), which is already
implemented in the EnterpriseSecurityException constructor and maybe 1 or 2
other exceptions. I admit, though, I'm not sure how maven deals w/ the
dependencies so that could certainly be an issue - any maven experts can you
We do use a few of the esapi classes.
- IntrusionDetector interface
- SecurityConfiguration class
- I think we might use the StringUtilities in a place or 2, but we could
remove these if need be
- use the logger through an adapter
- use the authenticator through an adapter.
We've planned ahead for integration w/ ESAPI or w/ other frameworks. In the
current incarnation of AppSensor, we do depend on ESAPI, but you don't have
to *use* ESAPI. You can use a different mechanism for all the controls that
ESAPI would normally cover, but if you use AppSensor, we're still gonna use
some ESAPI code behind the scenes. Having said that, our only
implementations for certain pieces are written for ESAPI integration
(logger/authenticator), but an app could easily implement their own.
I'm also curious about what "ESAPI can build a AppSensor implementation"
means from your perspective? Are you saying ...
1. use our code, and implement your own detection points and threshold
2. implement your own ground-up code/detection/response engine, as well as
the detection points and threshold configs -or-
3. something else
On Mon, Nov 1, 2010 at 2:58 AM, Jim Manico <jim.manico at owasp.org> wrote:
> I'd like to include AppSensor as the default intrusion detector for ESAPI
> via maven integration. It's way more powerful that our WAF. But the two do
> not complete, they are complimentary.
> I think we also want AppSensor to use the ESAPI logging methodology if we
> choose. This is difficult, and a little out of my league. (Circular
> dependency injection?).
> So I think...
> 1) AppSensor first stops using ESAPI...
> 2) AppSensor provides a pluggable logging mechanism so we can still force
> it to use ESAPI logging...
> 3) THEN ESAPI can build a AppSensor implementation and include it in the
> Does this make sense? Any thoughts Chris/August - I know you both have a
> lot more experience with this kind of integration.
> - Jim
> Hi, Glad you are considering AppSensor. I attempted answers inline - if
> you have further questions, let me know.
> On Sun, Oct 31, 2010 at 1:23 PM, Michael Coates <michael.coates at owasp.org>wrote:
> Forwarding to AppSensor mailing list. I think John will have the most
> current info for several of these questions.
> But, we do need to get the appsensor.jar as a feature download. We don't
> want people to build from scratch if they don't want to.
> -------- Original Message -------- Subject: AppSensor & ESAPI Date: Sun,
> 31 Oct 2010 09:37:31 -0400 From: Kevin W. Wall <kevin.w.wall at gmail.com><kevin.w.wall at gmail.com> Organization:
> Qwest IT - Application Security Team To: Michael Coates
> <michael.coates at owasp.org> <michael.coates at owasp.org>
> I just watched your AppSec USA 2010 video presentation about AppSensor & ESAPI
> yesterday. (Thanks for the credit as contributor BTW. Totally unexpected.)
> In it, you mentioned that it was planned to have appsensor.jar bundled with
> ESAPI as of ESAPI 2.0rc8. Since I don't see it in ESAPI even in 2.0rc10,
> I'm guessing that there was a delay for some reason.
> I copied Jim on this email b/c he was discussing this with us. I
> personally am not sure what's required on the ESAPI side to get AppSensor
> bundled. I can say AppSensor depends on ESAPI in some of it's code (ESAPI is
> a maven dependency of AppSensor). I would be happy to do whatever I can to
> get it included in the bundle. Jim, any thoughts?
> So then I go to look for the AppSensor tutorial and the AppSensor jar file
> at the AppSensor Google Code site and I don't find either. (The tutorial is
> under '/' of the trunk under the svn/trunk though, so I did get it.) But
> surprisingly (to me, at least) was the fact that I could not find appsensor.jar
> anywhere under the featured or previous Downloads. (Do you expect people to
> build it from scratch?)
> Right now, there are 3 ways to get the jar, and I agree this should be
> reorganized ... we all admit documentation is our next hurdle. The first is
> to build from scratch as you mentioned, unpalatable to most. The second is
> to grab the jar from the link on
> http://www.owasp.org/index.php/AppSensor_Developer_Guide. The third is to
> add it as a maven dependency - AppSensor is in Maven central (same as ESAPI
> as of 2.0RC10. We really do need to move towards producing a deliverable
> similar to ESAPI that is a zip w/ the jar/dependencies/javadoc/config files,
> etc. in a zip or something like that, but we're not there yet.
> Anyway, the reason that I am bringing this up is that I am about ready to
> start working on the ESAPI crypto for the 2.1 branch and I see many places
> where I'd like to wire-in AppSensor detection points into either JavaEncryptor
> or perhaps even EncryptionException. If AppSensor was truly bundled as part of
> ESAPI that would be fairly easy to do. OTOH, if it is not, I may need to
> rethink this because I don't want to create yet another dependency on an
> external class library. (ESAPI already has something like 30+ jars that it
> is dependent upon.)
> Glad you're thinking of going this way, again, I'd need to talk to Jim
> about bundling.
> Lastly, from your AppSec USA 2010 video, I recall you stating that that the
> way that AppSensor would be enabled in ESAPI would be to set
> in the ESAPI.properties file. However, I also vaguely recall discussion
> as to how that property should not be used as that would disable
> ESAPI's built-in WAF and I thought that I remember Jeff Williams arguing that
> AppSensor and the ESAPI WAF were _complimentary_ rather than _competing_
> technologies so therefore they should use different properties in ESAPI.
> Anyway, I am not sure that this has been resolved or not, so would appreciate
> an update in this area as well.
> This will probably have to be cleared up with Jeff and/or Jim. I haven't
> seen anything in the intrusion detector code that says anything about the
> WAF, but I could be wrong. I agree with Jeff's core point, but if that
> configuration is true, then I think the current setup is confusing. The WAF
> should have separate configuration. I wouldn't necessarily hook the WAF
> into the intrusion detection config, since some folks would want to use one
> or the other.
> Also wanted to point out that in addition to changing that 1-line config,
> you do need to add the appsensor.properties file (goes in the same folder as
> the esapi.properties), and make sure the config is right there. That config
> file is in svn.
> P.S.- If you wish to reply to the OWASP-AppSensor-Project mailing list, that's
> fine as I subscribe to that. Just wasn't sure if this was to appropriate
> to ask this there as I'm not sure if that's a developers list or a users
> Kevin W. Wall
> "The most likely way for the world to be destroyed, most experts agree,
> is by accident. That's where we come in; we're computer professionals.
> We cause accidents." -- Nathaniel Borenstein, co-creator of MIME
> Owasp-appsensor-project mailing list
> Owasp-appsensor-project at lists.owasp.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Owasp-appsensor-project