[Esapi-user] Fortify vs ESAPI 2.0

Jim Manico jim.manico at owasp.org
Thu Feb 3 07:56:55 EST 2011


Taint tracking is incredibly dangerous to depend on. I feel that secure coders should treat configuration data, database data, request input, and most any other system data as tainted. Even post-validated data should be treated as "tainted" if you want your code to stand the test of time.

If ESAPI offers a public function, we should treat those inputs as tainted. Again, even post validated data. Otherwise it does not belong in our "production quality security library".

-Jim Manico
http://manico.net

On Feb 3, 2011, at 12:52 AM, Chris Schmidt <chris.schmidt at owasp.org> wrote:

>> 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?
> 
> 
> _______________________________________________
> Esapi-user mailing list
> Esapi-user at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/esapi-user


More information about the Esapi-user mailing list