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

Michael Coates michael.coates at owasp.org
Tue Jun 22 13:59:21 EDT 2010


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-appsensor-project/attachments/20100622/b18af123/attachment.html 


More information about the Owasp-appsensor-project mailing list