[OWASP-ESAPI] Validation

[Jim Manico]

We should also consider changing:

    public boolean *isValidDataFromBrowser*(String context, String type, 
String value, int maxLength, boolean allowNull) throws IntrusionException;
    public String *getValidDataFromBrowser*(String context, String type, 
String value, int maxLength, boolean allowNull) throws ValidationException;
   
to

    public boolean *isValidString*(String context, String type, String 
value, int maxLength, boolean allowNull) throws IntrusionException;
    public String *getValidString*(String context, String type, String 
value, int maxLength, boolean allowNull) throws ValidationException;
 
There is no reason why it needs to be web centric.

- Jim  
>
> I’m glad to revisit this.  I definitely agree that there’s a need for 
> exception throwing validation methods.
>
>  
>
> There are good use cases for the boolean methods too.  I suggest 
> supporting BOTH.  This is already started with the isValidSafeHTML() 
> and getValidSafeHTML().  I propose extending this to ALL the data 
> types supported in Validator.
>
>  
>
> ·        *String getValidXXX( String context, String input, boolean 
> allowNull )* throws ValidationException - returns the canonical form 
> of the input if it passes validation.  Otherwise it throws a specific 
> validation exception that details the exact reason for the failure.  
> May throw an IntrusionException if the input is clearly an attack 
> (like double encoded characters)
>
>  
>
> ·        *boolean isValidXXX( String context, String input, boolean 
> allowNull )* – returns boolean if validation passes. Could throw an 
> IntrusionException if the input is clearly an attack (like double 
> encoded characters). Will typically delegate to the getValidXXX method 
> and return false if a ValidationException is thrown.
>
>  
>
> A few design choices:
>
>  
>
> 1)      Specific error messages.  To keep things simple, I propose 
> using ValidationException for all types of errors.  Each 
> ValidationException will contain a user message that provides a 
> user-safe description of the problem AND a log message, which has all 
> the details about specifically what is wrong.
>
>  
>
> 2)      Required parameters – See the “allowNull” parameter above. 
> Another option is to pass in the list of required and optional 
> parameter names when creating the Validator. But this seems too HTTP 
> request centric.
>
>  
>
> 3)      Length – It seems painful to have to define a separate regular 
> expression when the only thing that differs is the length. Does adding 
> a length parameter overcomplicate things?
>
>  
>
> 4)      More types – Have seen requests for more numeric types (with 
> ranges). What other types should we support out of the box.  Note that 
> we only need  special methods for types that can’t be specified easily 
> with a regex.  If a regex will suffice, then you can just use 
> getValidDataFromBrowser() with a type from the ESAPI.properties.
>
>  
>
> 5)      Building a list of all the error messages.  I think this is 
> best left to a framework.  But I could be convinced otherwise.
>
>  
>
> Please let me know your thoughts on these issues.  Thanks!
>
>  
>
> --Jeff
>
>  
>
> *From:* owasp-esapi-bounces at lists.owasp.org 
> [mailto:owasp-esapi-bounces at lists.owasp.org] *On Behalf Of *Jim Manico
> *Sent:* Saturday, April 12, 2008 4:09 AM
> *To:* 'owasp-esapi'
> *Subject:* [OWASP-ESAPI] Validation
>
>  
>
> Hello,
>
> I still think we need to make some major changes to the current ESAPI 
> Validation strategy.
>
> Summary:
>
> 1) Have most IValidator functions return the validated data, and throw 
> a org.owasp.esapi.errors.ValidationException on error.
> 2) I'm using ESAPI for a project that I'm currently working on - and I 
> have a need to validate integers for some fields, and doubles for others.
> 3) Number range checking is still missing.
>
> Examples:
>
> 1a) boolean isValidCreditCard(String context, String value); *goes away.
> *1b) String isValidCreditCard(String context, String value) throw 
> ValidationException *get added*
>
> 2a) boolean isValidNumber(String input);* goes away*
> 2b) Double isValidDouble(String input, double min, double max)* gets added
> *2b) Integer isValidInteger(String input, int min, int max)* gets added
>
> *Another reason why ALL boolean return values should go away for the 
> Validation strategy is that we need a */deeper message as to why 
> validation is failing./*
>
> If you give me the OK, Jeff, I'll make this change to the interface 
> and reference implementation myself.
>
> -- 
> Jim Manico, Senior Application Security Engineer
> jim.manico at aspectsecurity.com <mailto:jim.manico at aspectsecurity.com> | jim at manico.net <mailto:jim at manico.net>
> (301) 604-4882 (work)
> (808) 652-3805 (cell)
>  
> Aspect Security™
> Securing your applications at the source
> http://www.aspectsecurity.com


-- 
Jim Manico, Senior Application Security Engineer
jim.manico at aspectsecurity.com | jim at manico.net
(301) 604-4882 (work)
(808) 652-3805 (cell)

Aspect Security™
Securing your applications at the source
http://www.aspectsecurity.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-esapi/attachments/20080413/3626b368/attachment-0001.html