[Esapi-user] Fortify vs ESAPI 2.0
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".
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,
>> 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
>> 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
More information about the Esapi-user