[OWASP-ESAPI] Encoding implementation issue...

Jeff Williams jeff.williams at owasp.org
Wed Dec 9 16:35:55 EST 2009

We shouldn't escape characters that are just characters.  Otherwise people
will go insane that we're wasting bits.  In UTF-8, these characters will use
2 or 3 bytes (unless they're overlong).  Escaped, they'll use 7 bytes or
more per character.  There isn't good support for figuring this in Java 1.4.
But now that we've moved past Java 1.4, I think we can use
Character.isDefined(), Character.isLetterOrDigit(),
Character.isWhiteSpace(), Character.getType(), etc. to figure this out.
Anyone want to do a little research and suggest some pseudocode for this?


(we might want to update the password strength algorithm too, since it
should be Unicode safe and isn't)





From: Jim Manico [mailto:jim.manico at owasp.org] 
Sent: Wednesday, December 09, 2009 3:30 PM
To: 'Ed Schaller'
Cc: Jeff Williams; 'OWASP-ESAPI'; esapi-dev at lists.owasp.org
Subject: Re: [OWASP-ESAPI] Encoding implementation issue...


... and these characters are used rarely, so I feel that encoding them,
anyhow, will have minimal performance impact. I say we go for it. I'd rather
someone complain about performance (Like Knuth said, get it right first,
optimize later), than under-aggressive encoding.

- Jim

Hang on here...  I'm fairly sure that there's no reason to escape characters
above 0xFF for XSS purposes. The various parsers and interpreters in the
browser don't seem to recognize those characters as anything other than
normal text characters - not used for parsing or syntax.

Currently I know of no XSS or other attacks that are using characters
above 0xFF. The same could be said about characters above 0x7F or
characters not listed on the XSS cheat sheet. The principle however
is white listing vs. black listing. Just because we don't know about
issues with these characters does not mean that there aren't issues with
them. There are 1113856 code points above 0xFF. Additionally, even if
these characters aren't normal syntax characters doesn't mean that some
poorly implemented parser doesn't mess them up.



OWASP-ESAPI mailing list
OWASP-ESAPI at lists.owasp.org

- Jim Manico
OWASP ESAPI Project Manager
OWASP Podcast Host/Producer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-esapi/attachments/20091209/5b5adc04/attachment.html 

More information about the OWASP-ESAPI mailing list