[Esapi-user] ESAPI development process

Jim Manico jim.manico at owasp.org
Wed Aug 25 23:39:44 EDT 2010


Right on! :)

Bottom Line: The 2.0 rc6/7 encoder is *much* more robust. We need to
back-port the 2.0 encoder to 1.4. Any takers? :)

- Jim

-----Original Message-----
From: Jeff Williams [mailto:jeff.williams at aspectsecurity.com] 
Sent: Wednesday, August 25, 2010 1:14 PM
To: Patrick Higgins; Jim Manico
Cc: esapi-user at lists.owasp.org
Subject: RE: [Esapi-user] ESAPI development process

Hi Patrick,

I'm glad to see you diff'ed the encoding results.  The
encodeForJavascript() change is really important, as using \" could
allow an XSS attack.  As far as the unprintable characters go, they are
not allowed in HTML documents, not even as an HTML entity.  And there
are some attacks that make browsers go crazy using those characters,
like sending a million BEL characters.  Most browsers handle these well
now, but the behavior is unspecified.

Here's the comment from the encodeForHTML() method.

       /** 
          * Encode data for use in HTML using HTML entity encoding 
          * <p>  
          * Note that the following characters: 
          * 00-08, 0B-0C, 0E-1F, and 7F-9F 
          * <p>cannot be used in HTML.  
          *  
          * @see <a
href="http://en.wikipedia.org/wiki/Character_encodings_in_HTML">HTML
Encodings [wikipedia.org]</a>  
          * @see <a
href="http://www.w3.org/TR/html4/sgml/sgmldecl.html">SGML Specification
[w3.org]</a> 
          * @see <a href="http://www.w3.org/TR/REC-xml/#charsets">XML
Specification [w3.org]</a> 
          *  
          * @param input  
          *              the text to encode for HTML 
          *  
          * @return input encoded for HTML 
          */ 
         String encodeForHTML(String input); 
   


--Jeff

Jeff Williams, CEO
Aspect Security
work: 410-707-1487
main: 301-604-4882


-----Original Message-----
From: esapi-user-bounces at lists.owasp.org
[mailto:esapi-user-bounces at lists.owasp.org] On Behalf Of Patrick Higgins
Sent: Wednesday, August 25, 2010 3:31 PM
To: Jim Manico
Cc: esapi-user at lists.owasp.org
Subject: Re: [Esapi-user] ESAPI development process

On Wed, Aug 25, 2010 at 1:18 PM, Jim Manico <jim.manico at owasp.org>
wrote:
>> 1. Is there any documentation on the ESAPI development process? A 
>> "how to
> contribute/get involved" guide?
>
> There are only 4 active committers right now. I manage the project 
> over email. We do not have project documentation around out process 
> (Agile/Small Team), but I do code review (as does Jeff) on all diff's.

So should I submit patches to the -dev mailing list or just create
issues in the issue tracker and attach patches there?

> 2. From the Google Code people page, I see 18 people that have SVN 
> commit access. What controls are there to prevent 
> unreviewed/unapproved changes from being made?
>
> See above. I also just pruned this list down to just the 4 active 
> folks and moved others to "contributor" status. I'll prune this list 
> on a regular basis.

Thanks for pruning the list. That made me a little nervous!

> I do not use formal tagging, but I add a checkin note saying "Version 
> X final".
>
> I only release JAR's when I want the dev community to review. I now 
> release all *real* released as a complete zip. (This is why you see 
> ESAPI 2.0 rc6 as a zip, and ESAPI rc7 (early release) as a jar. ESAPI 
> rc7 is not ready for release, but will be in a few days. At that time 
> I will deprecate the ESAPI 2.0 rc6 zip and the rc7 jar - and upload
the rc7 zip.

The ESAPI-2.0-rc6.zip doesn't appear to have any build scripts. Was that
an oversight?

> For output encoding, yes. I fixed the thread-safely issue in ESAPI 2.0

> rc7 jar - I'd love your help in backporting that to 1.4.

I'm working on some 1.4 fixes now.

I'm not comfortable with the 2.0 upgrade right now given some
differences in encoding. I've attached a table with all the differences
I found when encoding all characters from 0 to Character.MAX_VALUE. The
ones that concern me are the unprintable characters that have been
replaced with spaces. I am not certain that some of our users aren't
using those values--they have some unusual data at times. Is there an
explanation of that change somewhere? Are there security concerns with
allowing those characters through as entity-encoded values rather than
replacing them with space characters?

--Patrick



More information about the Esapi-user mailing list