[Esapi-user] Fortify vs ESAPI 2.0

Kevin W. Wall kevin.w.wall at gmail.com
Thu Feb 3 01:07:49 EST 2011

On 02/03/2011 12:22 AM, Jim Manico wrote:
>> Our current isValidFileName validation is only as good as the regexp - and
>> while I think that regexp is probably pretty solid, it isn't bulletproof in
>> every system - after all, '/etc/passwd' is indeed a valid path is it not -
>> likewise, so is new File("../../../../../../../etc/passwd");
> That is why we have Validator.getValidDirectoryPath functions. Theses
> are not RegEx based and stop path traversal attacks of this nature - in
> any OS.

Yes, but Chris' statement about documentation...let me repeat it here...
> I think it is equally important to document that arguments containing
> untrusted or unknown data should be *contextually validated* before being
> passed into these utility functions to really knock the security out of the
> park.

Is still appropriate. The goal should be to make it easy to do the right
thing and hard to do the wrong thing, and *NOT* to make it impossible
to do the wrong thing. You will never be able to make something 100%
fool-proof, because, as they say, fools are so ingenious at screwing
things up.

And as far as the documentation goes, I would content if you don't have
good documentation and you have confusing issues similer to your
isValidFileName vs. getValidDirectoryPath there's a better than even
chance that the developer is going to reach for the wrong tool in
the tool shed.

The other argument against doing what you are proposing is the whole
simplicity vs. complexity argument. In that regard, sprinkling validation
here and there will make the code more complex as well as having somewhat
worse performance (which, IIRC, you were also recently ranting about ;-).

As we all know, complexity is the enemy of security. We already have things
overly complex in that there are several ways of doing something. (I can
hardly wait to see the ESAPI for Perl version!!! :)  And since
documentation in terms of "best ESAPI practice" is sorely missing, we
provide little guidance there. ESAPI is a toolbox full of tools, but
you just don't dump a bunch of tools on someone who has never used
them w/out instructions do you.

In this particular case, I would say create an ESAPI issue. Then we can
decide what to do with it. Most commercial software development efforts
that I have been involved with have a "bug fixes" review board for lack
of a better term. They have schedules and deadlines and a budget for a
reason. And this review board decides what bug fixes will go into a
particular release and what will be deferred to the next release. But
if they didn't have a schedule, they would be doing the same thing that
we are doing, which is to drag out the release date to get one more
bug fixed. It happens. (Maybe you should go work for the Debian crew! :)

Oh, one last observation. I recall some emails from you back when I first
started contributing to ESAPI 2.0 in July/Aug 2009, that you had mentioned
that you wanted to have the GA release in 3 or 4 months. Then it was
Jan/Feb, and then April, and now we are in Feb 2010. Progress has been
made, but perfection is not within our grasp and it never will be. But
in my company, I've been holding off folks from using ESAPI until
2.0 was GA'd. How much longer to I have to have them wait? Because
having something that works is better than not having them address
vulnerabilities at all. And I suspect that my company is not the
only company in that position.

Kevin W. Wall
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents."        -- Nathaniel Borenstein, co-creator of MIME

More information about the Esapi-user mailing list