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

John Melton jtmelton at gmail.com
Tue Jun 22 22:09:25 EDT 2010


Just wanted to point out 2 additional items.
- In reference to the config section from the ESAPI.properties file,
AppSensor uses a class that reads in the ESAPI.properties file as well as
the appsensor.properties file, and treats them as a merged list.  Therefore,
technically, the config for the threshold information could be in either
file.
- The other point to note here is that AppSensor does use the same config
format as the reference intrusion detector at the moment, and includes the
same response actions (as well as some additional options).  This means that
if you've already configured thresholds for the various exception types,
that data will continue to be used in the same way if you switch to using
AppSensor.
Thanks,
John

On Tue, Jun 22, 2010 at 1:59 PM, Michael Coates <michael.coates at owasp.org>wrote:

>  Kevin,
>
> Thanks for your questions.  My responses are below. By all means, keep the
> questions coming. We can use these questions to help build an FAQ to help
> others that are new to AppSensor.
>
> Michael Coates
> OWASP
>
>
> On 6/22/10 5:48 AM, Jeff Williams wrote:
>
>  Here's my understanding, but I'd really like to get Michael's
> interpretation too.
>
>
>
> 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?
>
>
>
> Although there is a bit of overlap in the input validation area, there **
> is** a difference in intent and capability. To me, the primary WAF use
> case is to block attacks with **known** signatures (virtual patch). Of
> course it can do positive HTTP validation and other things as well. The
> IntrusionDetector, on the other hand can detect **unknown** attacks using
> much more general heuristics and contextual information from the entire
> application, not just the request and response.
>
> AppSensor can be seen as an enhanced alternative to ESAPI's intrusion
> detector. AppSensor is not a replacement for the ESAPI WAF, nor is AppSensor
> a WAF at all.  AppSensor works by deep integration into the application to
> identify custom application attacks that could not be detected by a WAF. A
> prime example is an access control violation via direct object tampering
>
> www.site.com?account=1234
> www.site.com?account=1235
>
> An attacker attempting to exploit weak access control policies may
> enumerate the direct object references to hopefully gain access to another
> account's data. A good app will throw access control denied errors on each
> attempt. AppSensor is positioned within the application so that an AppSensor
> specific exception could also be created in this situation.  This allows
> AppSensor to record the malicious event against the specific user. Once a
> defined threshold is reached, AppSensor logs out the user (or locks them,
> emails someone, whatever).  This is the idea of AppSensor; placing detection
> points within the app to see attack activity that is specific and targeted
> to a unique app and then tie these actions back to the logged in user. These
> attacks are typically otherwise invisible to a WAF with no application
> specific knowledge and the WAF often lacks the ability to take action
> against the malicious user. All the detection points are listed here:
> http://www.owasp.org/index.php/AppSensor_DetectionPoints
>
>
>
> 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?
>
>
>
> This is exactly the contract that the IntrusionDetector (AppSensor) is
> intended to fulfill. The IntrusionDetector implementation is notified of
> all EnterpriseSecurityExceptions. The job of the detector is to identify
> attacks in that stream of events and respond to them in realtime. This type
> of attack could never be identified by the WAF.
>
>  --Jeff
>
>
> Yep. This is the idea.  Within the application cypto's code you would
> perform sort of check for the padded oracle attack. If you detected this
> attack then you would add one more line to create the appsensor exception.
> At this point you could choose to also add a message to be displayed to the
> user, or just leave that blank.  After this, the AppSensor code would take
> over to again record the attack event against the particular user and take
> responsive action if necessary.
>
> Pseudo Code
> if (oracle padded attack){
>
> new AppSensorException("ECE1", "(optional user msg) Sorry user, you are bad", "(system log message) Attacker is attempting an Oracle Padded Attack);
>
> }
>
>
>
> 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?
>
>
> Good catch. We need to add a little more info here.  After setting the
> intrusion detector to AppSensorIntrusionDetector then the user needs to
> customize the appsensor.properties document. This is basically an enhanced
> version of the ESAPI Intrusion Detection properties file.  So essentially
> the portion of the ESAPI.properties file that you've mentioned below is no
> longer used by ESAPI (or AppSensor).
>
>
>
> 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
>
> _______________________________________________
>
> Esapi-dev mailing list
>
> Esapi-dev at lists.owasp.org
>
> https://lists.owasp.org/mailman/listinfo/esapi-dev
>
>
> _______________________________________________
> Esapi-dev mailing list
> Esapi-dev at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/esapi-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-appsensor-project/attachments/20100622/a5506610/attachment-0001.html 


More information about the Owasp-appsensor-project mailing list