[Owasp-appsensor-project] [Esapi-dev] AppSensor & ESAPI Integration

Kevin W. Wall kevin.w.wall at gmail.com
Tue Jun 22 08:02:13 EDT 2010


Michael,

Michael Coates wrote:
> ESAPI Team,
>
> The AppSensor team has been working hard over the last several months to
> create an AppSensor jar that is ready for ESAPI integration.
>
> AppSensor is a project to enable detailed attack intrusion and response
> within application by integrating "detection points" into the
> application itself (think detecting all access control failures,
> malicious input, unexpected commands and more and then correlating that
> against the logged in user and logging out/locking the attacker). That's
> just the basics, more info on AppSensor here:
> http://www.owasp.org/index.php/Category:OWASP_AppSensor_Project
>
> Here are the instructions for easily updating an existing ESAPI
> application to use AppSensor. I encourage those interested to take a
> quick read and respond with any comments.
>
> http://www.owasp.org/index.php/AppSensor_GettingStarted
>
> What's next:
> 1. We'd like to use the Getting Started guide as an initial strategy for
> users to begin leveraging AppSensor in their ESAPI apps. We're looking
> for interested parties to begin using AppSensor within ESAPI and provide
> their feedback.
> 2. It would also be great for the ESAPI config to contain the
> configuration line for AppSensor and a link to the getting started page.
>
> #Use OWASP AppSensor for enhanced application intrusion detection and
> response
> #See http://www.owasp.org/index.php/AppSensor_GettingStarted for
> necessary JAR and configuration
>
#ESAPI.IntrusionDetector=org.owasp.appsensor.intrusiondetection.AppSensorIntrusionDetector
>
> Thoughts and feedback please.

I've been following the AppSensor work for awhile now, but there has always
been a few points of confusion as it related to ESAPI and I suspect that other
ESAPI developers may have the same questions. Since I've really not dug into
AppSensor and done anything hands-on, my questions may be a bit naive, but
I'll hope you'll bare with my ignorance.

Anyhow, as you are no doubt aware, ESAPI also has a Web Application Firewall
(WAF) as one of its features. Do you see AppSensor as *replacing* this
built-in WAF or as augmenting it? If the former, what are the advantages of
using AppSensor rather than ESAPI's WAF feature? If it is to augment it, could
you explain how it does this because it would seem to me that there is a lot
of overlapping functionality. Is there some difference in _intent_?
Or is ESAPI's WAF simply a JavaEE Servlet Filter that invokes a more
rudimentary intrusion detector (DefaultIntrusionDetector) and
AppSensor is simply a more advanced version of an intrusion detector?

My second question is about the intrusion detection properties built into ESAPI.
Your Getting Started wiki page mentions replacing
ESAPI.IntrusionDetector=org.owasp.esapi.reference.DefaultIntrusionDetector
with
ESAPI.IntrusionDetector=org.owasp.appsensor.intrusiondetection.AppSensorIntrusionDetector

but there are also these other properties (see below). Do these properties also
control AppSensor or does it have it's own config file?

E.g., from the latest ESAPI.properties:

#===========================================================================
# ESAPI Intrusion Detection
#
# Each event has a base to which .count, .interval, and .action are added
# The IntrusionException will fire if we receive "count" events within
"interval" seconds
# The IntrusionDetector is configurable to take the following actions: log,
logout, and disable
#  (multiple actions separated by commas are allowed e.g.
event.test.actions=log,disable
#
# Custom Events
# Names must start with "event." as the base
# Use IntrusionDetector.addEvent( "test" ) in your code to trigger "event.test" here
# You can also disable intrusion detection completely by changing
# the following parameter to true
#
IntrusionDetector.Disable=false
#
IntrusionDetector.event.test.count=2
IntrusionDetector.event.test.interval=10
IntrusionDetector.event.test.actions=disable,log

# Exception Events
# All EnterpriseSecurityExceptions are registered automatically
# Call IntrusionDetector.getInstance().addException(e) for Exceptions that do
not extend EnterpriseSecurityException
# Use the fully qualified classname of the exception as the base

# any intrusion is an attack
IntrusionDetector.org.owasp.esapi.errors.IntrusionException.count=1
IntrusionDetector.org.owasp.esapi.errors.IntrusionException.interval=1
IntrusionDetector.org.owasp.esapi.errors.IntrusionException.actions=log,disable,logout

# for test purposes
# CHECKME: Shouldn't there be something in the property name itself that designates
#		   that these are for testing???
IntrusionDetector.org.owasp.esapi.errors.IntegrityException.count=10
IntrusionDetector.org.owasp.esapi.errors.IntegrityException.interval=5
IntrusionDetector.org.owasp.esapi.errors.IntegrityException.actions=log,disable,logout

# rapid validation errors indicate scans or attacks in progress
# org.owasp.esapi.errors.ValidationException.count=10
# org.owasp.esapi.errors.ValidationException.interval=10
# org.owasp.esapi.errors.ValidationException.actions=log,logout

# sessions jumping between hosts indicates session hijacking
IntrusionDetector.org.owasp.esapi.errors.AuthenticationHostException.count=2
IntrusionDetector.org.owasp.esapi.errors.AuthenticationHostException.interval=10
IntrusionDetector.org.owasp.esapi.errors.AuthenticationHostException.actions=log,logout


#===========================================================================


Finally, a last question. It seems to me that some intrusion attempts can best
be detected from deep within ESAPI where the relevant context is available. A
good example of this is if someone were to be attempting a known ciphertext
attack on ESAPI's crypto, such as the Padded Oracle attack described by Rizzo
and Duong. In such cases, is adding explicit intrusion detection points required
or is it sufficient to just through some exception derived from ESAPI's
EnterpriseSecurityException class? In the case of crypto at least, there are
different things that can go wrong, but you need to be very careful not to
reveal what went long as that can leak information to an attacker leading to
a successful attack. (Such is the case with the Padded Oracle attack.)

Thanks,
-kevin
-- 
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


More information about the Owasp-appsensor-project mailing list