[Esapi-user] Fortify vs ESAPI 2.0

Chris Schmidt chris.schmidt at owasp.org
Thu Feb 3 01:52:37 EST 2011


> 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.)

I'm not intimately familiar with all the specifics of how taint mode works
in Perl, however, I get the concept. I agree this is a complicated problem
to solve, and I think this is a good use-case for AOP. RT bytecode weaving
is painful, dangerous, and a performance killer - but compile time bytecode
weaving is a whole different story. There are also some ways to do this
using dynamic proxies to the primitive wrapper objects. Maybe something to
look into as a side OWASP project - OWASP TaintTracker anyone?




More information about the Esapi-user mailing list