[Esapi-user] [Esapi-dev] Has anyone created a "UserEffect" kind of ESAPI control...

Jeff Williams jeff.williams at aspectsecurity.com
Mon Apr 26 17:41:08 EDT 2010


I like the idea of leveraging the crypto red/black diagram style, but I’m sorry, I don’t get the one below.  To me there are only four states…

 

·         Raw

·         Canonicalized

·         Validated

·         Escaped

 

But that’s not really that important.  There really two important integration questions for preventing injection.

 

·         How do you hook up ESAPI validation?  Here you have to find the place where your framework is doing validation.  If it’s extensible (like Struts pluggable validators) then you can just use that to plug in ESAPI.  If it’s not extensible, then you’ve got an “engineering challenge” – either you have to switch to only ESAPI, or you have to modify the framework.

 

·         How do you hook up ESAPI escaping? Here you have to find all the places where your application emits data that isn’t 100% trusted.  Usually this is UI or data layer. Then you have to properly escape any data before it leaves.  Now if you have a component UI, then you can modify your custom components to use ESAPI escaping.  But you’ll also have to check the “standard” components that come with the framework, as in most libraries they are horribly inconsistent about escaping.

 

--Jeff

 

 

From: esapi-dev-bounces at lists.owasp.org [mailto:esapi-dev-bounces at lists.owasp.org] On Behalf Of Boberski, Michael [USA]
Sent: Monday, April 26, 2010 3:51 PM
To: Jim Manico
Cc: ESAPI-Developers; ESAPI-Users
Subject: Re: [Esapi-dev] [Esapi-user] Has anyone created a "UserEffect" kind of ESAPI control...

 

Maybe, a “state” pattern would be one way to provide at least some initial guidance on hooking ESAPI up to frameworks etc. that we can put in our new documentation, something like:

 

 

 

Since, there’s nothing equivalent in terms of a picture in “doc-files” or other written guidance along the lines of either of your guys’ responses that I can find.

 

Best,

 

Mike B.

 

From: esapi-user-bounces at lists.owasp.org [mailto:esapi-user-bounces at lists.owasp.org] On Behalf Of Boberski, Michael [USA]
Sent: Monday, April 26, 2010 1:03 PM
To: Jim Manico
Cc: ESAPI-Developers; ESAPI-Users
Subject: Re: [Esapi-user] Has anyone created a "UserEffect" kind of ESAPI control...

 

Jeff and Jim, thanks. 

 

I think based on your responses, there might be a fourth (maybe more?) “design pattern” related to validation lifecycle as you call it, to be extracted and added here: http://code.google.com/p/owasp-esapi-java/wiki/esapi4java_v2_Design_patterns 

 

I’ll think about it further…

 

Thanks both,

 

Best,

 

Mike B.

 

From: Jim Manico [mailto:jim.manico at owasp.org] 
Sent: Monday, April 26, 2010 11:15 AM
To: Boberski, Michael [USA]
Cc: ESAPI-Users; ESAPI-Developers
Subject: Re: [Esapi-user] Has anyone created a "UserEffect" kind of ESAPI control...

 

Mike,

 

I use the ValidationGroup class to ensure that each validation attempt for each field still fires even if the first one fails. Then I check if that list is empty and act accordingly. I pass error messages from the controller to the UI via a request attribute - so that the header tile of my app will list the error messages. I also access the error list at my body tile so I can highlight certain fields that are in error.

 

This is the "full lifecycle" of validation and I think ESAPI covers it well.

 

Most validation errors are just honest user mistakes - missing a required field or adding a bad character that breaks a regex.  

 

But for validation errors that are extrodinary - I just use the IntrusionDetector.

 

Forgive me if I'm missing something sir. :) Can you explain to me just one more time were this proposal fits into the validation lifecycle? 


Jim Manico


On Apr 26, 2010, at 7:56 AM, "Boberski, Michael [USA]" <boberski_michael at bah.com> wrote:

	… that triggers on failures, regardless of IntrusionDetector use/configuration?

	 

	E.g., to wrap HTTP 500 error message generation, or e.g. to do a lookup for some kind of context-specific error to display on a user form, and hook this up to other ESAPI controls?

	 

	E.g.,

	 

	if( !validator.isValidXX() ) {

	    ESAPI.effect().rejectUserInput(); //maybe, generate an HTTP 500, cause a form error, ?

	}

	 

	This would be towards the end of standardizing how e.g. user input validation failures (ESAPI isWhatever failures and failures causing exceptions to be thrown more generally) should be handled. I think by adding an interface to ESAPI might help proactively answer (and promote the wrapping and standardization of security-relevant behaviors inside of ESAPI) what is one of the first questions dev teams ask me on how to use ESAPI. 

	 

	If I’m missing something obvious, please be kind, and explain what the/a preferred approach using ESAPI is, to wrap and standardize such things for an application, generally/according to best practices.

	 

	Best,

	 

	Mike B.

	_______________________________________________
	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-user/attachments/20100426/0eb8b84c/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 30586 bytes
Desc: image001.png
Url : https://lists.owasp.org/pipermail/esapi-user/attachments/20100426/0eb8b84c/attachment-0001.png 


More information about the Esapi-user mailing list