[Esapi-dev] [Esapi-user] disabling logging

Tue Sep 28 18:28:15 EDT 2010

(moving to dev list)

Jeff,

> I certainly wouldn't want to see a global switch that would turn off
double-encoding checking for everything

I agree 100%. 

You CAN make this use-case work with ESAPI. You could use the Encoder() to
do URL decoding twice on this specific piece of input, and THEN use the
Validator to validate with a app specific regular expression (which would
also do double decoding protection via canonicalization that is built into
validation). This would still do good validation while not breaking the app
(and input) in question.

This only becomes a problem when using the SecurityWrapper. But Jeff, as it
is, the SecurityWrapper breaks most apps. It's very restrictive. We need to
make it more configurable to make it usable.  An email address is a
reasonable input, and @ is not allowed in the SecurityWrapper as it is
today. All request parameters are restricted by ^[a-zA-Z0-9.\\-\\/+=_ ]*$ if
you use the SecurityWrapper today

Validator.HTTPParameterValue=^[a-zA-Z0-9.\\-\\/+=_ ]*$

I think we should make the default value a little more open - at least add a
few more characters. I'm just not sure what changes are best.

- Jim

From: Jeff Williams [mailto:jeff.williams at aspectsecurity.com] 
Sent: Tuesday, September 28, 2010 12:11 PM
To: augustd; Jim Manico; Esapi-user at lists.owasp.org
Subject: RE: [Esapi-user] disabling logging

Hmm.August is right.  This isn't the IntrusionDetector.  This is an
IntrusionException thrown directly by the canonicalize() method when it
encounters double-encoding.   That's why disabling the IntrusionDetector
isn't helping here.

There are a few workarounds that would allow this to work, but I'm not sure
how far down this road we want to go.  In my opinion, having a
double-encoded cookie doesn't make a lot of sense and we shouldn't go out of
our way to accommodate it.

I certainly wouldn't want to see a global switch that would turn off
double-encoding checking for everything. That would seriously undermine the
protection we're providing in ESAPI.  I *might* be willing to consider yet
another parameter to allow someone to shoot themselves in the foot if they
really really want to.  But the number of parameters on Validation calls is
already too long.

--Jeff

From: esapi-user-bounces at lists.owasp.org
[mailto:esapi-user-bounces at lists.owasp.org] On Behalf Of augustd
Sent: Tuesday, September 28, 2010 4:03 PM
To: Jim Manico; Esapi-user at lists.owasp.org
Subject: Re: [Esapi-user] disabling logging

I've filed Issue #152 for this problem: 

http://code.google.com/p/owasp-esapi-java/issues/detail?id=152

-August 

On Tue, Sep 28, 2010 at 9:20 AM, <augustd at codemagi.com> wrote:

If your intention was to disable the intrusion detector and it still throws
IntrusionExceptions then I would say it is not good. 

-August

Sent via BlackBerry by AT&T

  _____  

From: "Jim Manico" <jim.manico at owasp.org> 

Date: Mon, 27 Sep 2010 18:55:28 -1000

To: 'augustd'<augustd at codemagi.com>; <Esapi-user at lists.owasp.org>

Subject: RE: [Esapi-user] disabling logging

So this is good, right?

From: augustd [mailto:augustd at codemagi.com] 
Sent: Monday, September 27, 2010 5:28 PM
To: Esapi-user at lists.owasp.org
Cc: Jim Manico
Subject: Re: [Esapi-user] disabling logging

I have a report from one of my users of IntrusionDetector.Disable not
working also: 

I have an exception coming from the Intrusion Detection in ESAPI, I tried
disabling it with: 

  IntrusionDetector.Disable=true

But that doesn't seems to be working.  The problem is with a cookie value
that we have.  It seems to be double encoded and the Intrusion Detection
throws an exception so the loading of the page fails.

Here's the exception

2010-09-27 18:00:50,811 INFO  [STDOUT] 2010-09-27 18:00:50,810 ERROR
[some.server.com%2F12.34.56.78-8009-1] Log4JLogFactory$Log4JLogger -
[SECURITY FAILURE Anonymous:null at unknown ->
some.server.com:443/ExampleApplication/IntrusionException] INTRUSION -
Multiple (2x) encoding detected in XXXXXXXXXXXXXXXXXXXXX

2010-09-27 18:00:50,812 INFO  [STDOUT] 2010-09-27 18:00:50,811 ERROR
[some.server.com.com%2F12.34.56.78-8009-1] Log4JLogFactory$Log4JLogger -
[SECURITY FAILURE Anonymous:null at unknown ->
some.server.com:443/ExampleApplication/com.server.some.SecurityWrapper]
Error in SecurityWrapper: Input validation failure

org.owasp.esapi.errors.IntrusionException: Input validation failure

        at
org.owasp.esapi.reference.DefaultEncoder.canonicalize(DefaultEncoder.java:16
9)

        at
org.owasp.esapi.reference.DefaultEncoder.canonicalize(DefaultEncoder.java:12
0)

        at
org.owasp.esapi.reference.validation.StringValidationRule.getValid(StringVal
idationRule.java:290)

        at
org.owasp.esapi.reference.DefaultValidator.getValidInput(DefaultValidator.ja
va:173)

I dug into the code and it looks like StringValidationRule.getValid( String
context, String input ) calls the one-argument
DefaultEncoder.canonicalize(String input) which automatically enforces
strict intrusion detection regardless of the value in ESAPI.properties. 

-August 

On Fri, Sep 24, 2010 at 6:59 AM, Saad Shakil <sshakil at rim.com> wrote:

But intrusion detection sounds like something I should be keeping :)

Other than validation against the regex, what else does IntrusionDetector
do?

From: Jim Manico [mailto:jim.manico at owasp.org] 
Sent: Thursday, September 23, 2010 8:36 PM
To: Saad Shakil; Esapi-user at lists.owasp.org
Subject: RE: [Esapi-user] disabling logging

Yes, just disable Intrusion Detection and this problem should go away. To do
that, please just add the following to your copy of ESAPI.properties

IntrusionDetector.Disable=true

From: esapi-user-bounces at lists.owasp.org
[mailto:esapi-user-bounces at lists.owasp.org] On Behalf Of Saad Shakil
Sent: Thursday, September 23, 2010 10:38 AM
To: Esapi-user at lists.owasp.org
Subject: [Esapi-user] disabling logging

I tried setting <priority value ="off" /> in log4j.xml, but still noticed an
IntrusionDetector SECURITY FAILURE on a validation exception that I catch in
my code.

Secondly, separate validation and intrusion exceptions become redundant if a
third intrustiondetector is already thrown.  IntrusionDetector.class reads: 

"This method should immediately log the exception so that developers
throwing an IntrusionException do not have to remember to log every error."

 I understand that the way we can catch an attack is through validation
failure, but what distinguishing a harmless error from an actual attack?
Right now, I have it so that I violate the default 'AccountName' rule by
trying to update the value to one that is of length 2 characters, when the
min is three .{3,100}$.  I haven't dug deep inside ESAPI code, but this
shouldn't be treated as an exception in my case, rather just an invalid
input.  And I'd like to change the logging to reflect that, and the event's
handling too if possible.  Any idea on how I can go about doing this?

Thanks.

-S

--------------------------------------------------------------------- 
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute non-public
information. Any use of this information by anyone other than the intended
recipient is prohibited. If you have received this transmission in error,
please immediately reply to the sender and delete this information from your
system. Use, dissemination, distribution, or reproduction of this
transmission by unintended recipients is not authorized and may be unlawful.

--------------------------------------------------------------------- 
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute non-public
information. Any use of this information by anyone other than the intended
recipient is prohibited. If you have received this transmission in error,
please immediately reply to the sender and delete this information from your
system. Use, dissemination, distribution, or reproduction of this
transmission by unintended recipients is not authorized and may be unlawful.

_______________________________________________
Esapi-user mailing list
Esapi-user at lists.owasp.org
https://lists.owasp.org/mailman/listinfo/esapi-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/esapi-dev/attachments/20100928/ecd977f4/attachment-0001.html 