[OWASP-ESAPI] [Owasp-dotnet] ESAPI.NET

[Jeff Williams]

> FxCop flags code that catches base exceptions - see an explanatory  
> blog post here: http://blogs.msdn.com/fxcop/archive/2006/06/14/631923.aspx

Interesting argument. The way I read it, the idea is that you should let
your application crash so that you can find out what's going on internally
and fix it. I think we're better off failing closed here.

>> You need the get* methods because of canonicalization. As Rogan  
>> pointed out,
>> you can't validate the canonical version and then allow the  
>> developer to
>> continue with the non-canonical form.
>
> OK, that makes sense. What is the rationale for leaving in the is*  
> methods then?

The is* methods are there to keep calling code concise in places where you
just need to know if validation failed or not. For example, perhaps in your
UI, you want to display fields that fail validation in red.  Then you can
just call the is* method without all the try-catch bulk.  Make sense?

The same pattern is followed in the AccessController, where you need the
assert* calls in your business logic (try assertAuthorized, catch attack),
but the is* calls in your user interface (e.g. display button if
isAuthorized).

>>> and the other is the allowNull boolean
>> Allow null allows easy support for optional parameters, so that the  
> Is null ever valid input? :) To me, data should be marked optional at  
> the level of a parameter set. This raises some interesting points. The  
> ESAPI validation strategy is focused on independent data. What about  
> dealing with data that depends upon other data - two passwords that  
> need to match, or a city parameter that needs to be in a state  
> parameter? Perhaps we could have a mechanism for validating a  
> parameter set. I think this is where optional parameters need to be  
> specified. Implementing this kind of validation strategy against  
> parameter sets can get ugly, as we've seen in other validation  
> libraries, so we would need to think it through and see if it can be  
> done well.

I can imagine adding this in the future, but I want to focus on creating
super-high quality validation primitives first.

> OK. I'm afraid it would get abused by lazy developers who would simply  
> pass garbage, because it's not entirely clear what to pass in,  
> although perhaps documentation would help. I think that a stack trace  
> would be necessary to determine where the data actually came from, so  
> it seems like the context could be overkill. I'm not particularly  
> opposed to it though.

The stack trace is about where the *call* came from, and the context is
about where the *data* came from. Knowing that the exception was thrown in a
certain servlet isn't going to tell you the name of the HTTP parameter that
was broken. That's probably the most useful piece of diagnostic information
to the developer, and why we added it to the call.

Great discussion.

--Jeff