[Esapi-user] Fortify vs ESAPI 2.0
Kevin W. Wall
kevin.w.wall at gmail.com
Thu Feb 3 00:16:47 EST 2011
On 02/02/2011 11:42 PM, Jim Manico wrote:
> I very strongly disagree, Chris. Utility functions like this should have
> validation built in (like our file validation APIs). There is no excuse
> to NOT add this validation in - especially for public utility functions.
> We are a security library after-all...
> McGraw was right all this time. Build Security In!
I can see both points of view here. How about we provide a SafeBase64
class that simply does the proper checking in the SafeBase64 wrapper
class and then calls Base64 and then, as Chris suggests, just documents
the Base64 methods with an appropriate caveat?
I think that one argument for not changing Base64.java much (or, at all),
is that it is simply borrowed from the public domain version at
http://iharder.net/base64, which last time I looked was at version 2.3.3.
The version that ESAPI uses is from version 2.2.2. (See CHECKME comments I
added at the beginning way back when.) If we keep Base64.java as close to
pristine as possible it will make it easier to diff from previous versions
to see if we want to pick up the fixes.
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