[OWASP-ESAPI] Comments on ESAPI

[Jeff Williams]

I haven't packaged these up, but it's a good idea.  I'll update the build
script to generate a zip file of the JavaDoc.  In the meantime, you can
always fire up subversion and grab a copy of any version of the JavaDoc you
like.

--Jeff


-----Original Message-----
From: Rohit Lists [mailto:rklists at gmail.com] 
Sent: Monday, July 14, 2008 10:33 PM
To: jeff.williams at owasp.org
Cc: OWASP-ESAPI at lists.owasp.org
Subject: Re: [OWASP-ESAPI] Comments on ESAPI

Jeff,

Is there an older version of the JavaDoc that people can use for the
time being when they download ESAPI v1.1.1? Also it might help to
include in the description of the link to the JavaDoc what version the
documentation reflects.

Thanks,

Rohit

On Mon, Jul 14, 2008 at 9:16 PM, Jeff Williams <jeff.williams at owasp.org>
wrote:
> Thanks Rohit!
>
>> 1. Can we update the JavaDoc currently at
>> http://owasp-esapi-java.googlecode.com/svn/trunk/javadoc/index.html?
>> If people start using ESAPI as a true API, they'll be relying heavily
>> on the JavaDoc.
>> I noticed a few things are out-of-sync, e.g. JavaDoc talks about
>> Encoder Interface and DefaultEncoder reference implementation, while
>> the code has IEncoder interface and Encoder reference implementation
>
> Actually, the Javadoc is more up to date as it matches the current SVN
> baseline.
>
>> 2. I imagine many organizations will be using only some rather than
>> all parts of the ESAPI. To that end, it would make sense to have a
>> graph or list of dependencies (e.g. EncryptedProperties relies on
>> Encryptor). I can work on putting this together if you'd like
>
> Sure, that'd be great. But you should use the latest version from SVN.
>
>> 3. With respect to Encode methods such as encodeForHTML(), instead of
>> explicitly defining alpha-numeric characters in arrays, I wonder if it
>> makes more sense to use Character class isLetter(), isDigit(), or
>> isLetterOrDigit() calls -
>>
>
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Character.html#isLetterOrD
> igit(char)
>>. The reason I say this is that these methods support several
>> character sets (not just ISO-LATIN-1), which will help improve
>> adoption in applications that support other languages. Note that these
>> methods are already being used in EncodedCharacter.getEncoded()
>
> We definitely need some hard thought on how to make validation,
> canonicalization, and encoding work in international websites. Currently
the
> Validator allows for the use of regular expressions which can be
> internationalized.  There's also a provision for normalizing international
> characters if you'd like to use simple regular expressions.  But we need
to
> work out the full plan for making ESAPI work for international sites.
>
> On a related point, we need to internationalize all the messages in ESAPI.
> That'd be a great project for someone to help out with.
>
>> 4. For the encodeForSQL, the parameter string might still be
>> vulnerable to numeric field injection (1 OR 1=1). While I think the
>> idea of making RDBMS implementation is a great idea, I wonder if in
>> the meantime we can provide a encodeForSQLNumeric function that simply
>> ensures each character is numeric?
>
> As is made very clear in the Javadoc for that method, the right approach
> here is to use a PreparedStatement. What you're proposing isn't encoding,
> it's validation - and people should already be doing that with the
> Validator.
>
>> 5. Are there plans to implement BugZilla or some other bug tracking
>> mechanisms so that missing/incomplete features can be assigned to
>> specific owners and tracked? I noticed there are a lot of statements
>> like "// FIXME: look up rules" which may get lost if people aren't
>> looking at specific files.
>
> There is a bug tracking system in place at GoogleCode.
> http://code.google.com/p/owasp-esapi-java/issues/list.  Everyone is
welcome
> to put issues here.  We've fixed all but one of the issues that have been
> posted here.  The team is currently in the process of taking all the FIXME
> comments out of the code and putting them in the bugtracker.
>
> --Jeff
>
>
>
>



-- 
Rohit Sethi
Security Compass
http://www.securitycompass.com