[OWASP-ESAPI] Validation

[Jeff Williams]

A few updates here.

 

·        Added “get” methods for almost all the isValidXXX methods

·        Standardized parameter name and order a bit

·        Changed numeric methods to return primitive types (ok?)

·        Changed name of isValidDataFromBrowser to isValidInput

·        Removed HttpServletRequest from validateHTTPRequest signature (use getCurrent)

·        Renamed isValidParameterSet to isValidHTTPRequestParameterSet

·        Updated some of the Javadoc

 

Notes:



·        IntrusionException doesn’t have to be declared since it’s a RuntimeException, but I think it’s nice to have it there so people will see that it might happen in case of attack.  Also added these to the boolean signatures.

·        Method signatures in interfaces don’t need “public” – it gets flagged in FindBugs so I deleted them.

 

--Jeff

 

 

From: Jim Manico [mailto:jim at manico.net] 
Sent: Sunday, April 13, 2008 7:29 PM
To: jeff.williams at owasp.org
Cc: 'owasp-esapi'
Subject: Re: [OWASP-ESAPI] Validation

 

I've attached my proposal for the next generation of IValidator. Feedback greatly appreciated ASAP - I'd like to finish the reference implementation early in the week.

- 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:

 

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.

 

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.

 

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?

 

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.

 

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 | 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/20080414/4f4d48cc/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IValidator2.java
Type: application/octet-stream
Size: 12335 bytes
Desc: not available
Url : https://lists.owasp.org/pipermail/owasp-esapi/attachments/20080414/4f4d48cc/attachment-0001.obj