[Esapi-user] Fortify vs ESAPI 2.0

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


On 02/03/2011 12:35 AM, Chris Schmidt wrote:
[SNIP]

> I think that is really what all of my side of the debate boils down to -
> being a security API - should it be implied that the methods we provide will
> treat all data as untrusted data - when in fact, a good deal of the time -
> the code that calls utility methods like this will not in fact be calling it
> with untrusted data? (at least in any app that I wrote - perhaps that is
> just my way of thinking tho)
> 
> Then here is the real question - why is this method public? Why are we
> concerning ourself with exposing publicly utility methods of this nature
> when we should really be *only* exposing methods that are defined in the API
> itself, hence the purpose of the contract (interface)

Ah, I was wondering when you would get around to contracts. However, contracts--
at least in the sense of Meyer's Design-By-Contract--go way beyond interfaces.
And interface in and of itself will not tell you that they String you are
passing cannot be null or empty. We use javadoc for that, or precondition /
postcondition annotations if you prefer that route.

The *real* problem here goes way beyond syntax (interfaces) and includes
semantics. For a security API, part of those semantics are things like
ensuring methods are MT-safe unless otherwise documented and documenting
that which inputs are trusted and which are not. (If we had a naming convention
for untrusted input, it would make that case a whole lot easier.)

Unfortunately, dealing with untrusted input is a major pain in the
Heine-ken with out some language assistance. For example, doing a
lot of this stuff in Perl is a whole lot easier because of Perl's
'taint' mode. If Java had a TaintedInput marker interface and
derived TaintedString, TaintedInt, etc. subclasses, things would
be a whole lot easier. I have thought about this problem long and
hard and with the Servlet API being what it is, I don't think
you could make it fly unless it was something that you ran against
the byte-code to instrument it to do taint-checking. Anyway, I
digress, but the point is, you can't do *everything*. In this
*specific* case, we could do something, but in the general case,
sometimes you have to resort to documentation. (Besides, I know
of NO ONE who has had such confidence in their software that they
have not thought it necessary to exclude themselves from all
liabilities. Even ESAPI does this. So much for rugged software.)

[SNIP]

> Another question tho, regarding Kevin's comment - why are we copy/pasting
> code from another library? Is the purpose to not drag in another dependency?
> Seems like a huge antipattern to me to work it this way, but mayhaps there
> was a good reason behind doing this?

I blame it on Sun's myopia of why this Base64 is here. AFAIK, they never
had a *public* Base64 encoder in their JDK. (There is a com.sun one somewhere
in there if I'm not mistaken, but it's not in the Javadoc so even those who
know about it are reluctant to use it.) Consequently lots of FOSS
implementations sprung up, some better than others. Someone needed it
and probably partially vetted it and it got pulled in. It probably made
sense to pull one of the FOSS variants in and it pretty much had to be
one released under either BSD or was in the public domain. (This one is
the latter.) Something like one that was GPL could have totally messed up
the whole BSD licensing (but would have made RMS happy). I suspect that
there's probably one in Apache Commons somewhere, but that may have
been before ESAPI had it as a dependency or maybe it was just the first
one that popped up w/ agreeable licensing terms when someone Googled
for base64.

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