[Esapi-user] open text fields

Jim Manico jim.manico at owasp.org
Thu May 26 17:06:40 EDT 2011


If you •must• do this then talk to Adar Wiedman - he has a great deal of expertise writing regular expressions that audit other regular expressions for ReDoS issues. This addresses ReDoS when a user-driven regular expression is first submitted.

The second school of though is to execute Regular Expressions on a separate thread and kill execution after a few seconds has passed. This is a lot more fragile, especially when under heavy load.

Fun never ends ;)

Jim Manico

On May 26, 2011, at 2:20 PM, augustd <augustd at codemagi.com> wrote:

> I'd be very careful about allowing your users to specify regular expressions in this way. Google 'ReDoS'...
> 
> -August 
> 
> 
> On Thu, May 26, 2011 at 11:47 AM, ricardo gualberto <r_gualberto at hotmail.com> wrote:
> Hi Matthew,
>         thank you for your response. Some of the input data will be used in some code logic decision like the configurable regular expressions. Other fields are just descriptions that are stored on database. My application store all input data on database and we will bind queries to prevent things like SQL Injection. I'm new to ESAPI and have been reading the documentation but couldn't figure out how to handle this scenario which I think is quite common. Do you know of any documentation or sample code on how to handle this kind of input data?  
> 
> Regards,
>    Ricardo
> 
> Date: Thu, 26 May 2011 09:02:11 -0500
> 
> Subject: Re: [Esapi-user] open text fields
> From: matthew.presson at gmail.com
> 
> To: r_gualberto at hotmail.com
> CC: fcerullo at gmail.com; esapi-user at lists.owasp.org
> 
> 
> Open text fields, especially those that exist in applications that must support multiple locales, have always been tricky.  In the past, I have always taken the stance that the risk is acceptable not to do input validation on these types of fields as long as the following conditions are stringently met:
> 
>      1. The input provided in the field is not used in any type of business logic decision within the app
>      2. It is verified, through code reviews, that every place the input is ever displayed is properly encoded based upon the required context, e.g. HTML, JS, CSS, etc.
> 
> All-in-all, a developer should really be concerned about two* scenarios concerning input:
> 
>      1. Will the input be used in some code path execution/business logic decision?  If so, it MUST be validated.  This especially includes any authentication and 
>          authorization decisions.
>      2. Will the input be displayed back to the user?  If so, it must be encoded for the proper context when being displayed.
> 
> *This assumes that all database access code is using bindable queries to prevent things like SQL Injection.
> 
> _______________________________________________
> Esapi-user mailing list
> Esapi-user at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/esapi-user
> 
> 
> _______________________________________________
> 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/20110526/09a9035f/attachment.html 


More information about the Esapi-user mailing list