[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)

 

--Jeff

 

 

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
https://lists.owasp.org/mailman/listinfo/owasp-esapi
        






-- 
 
- Jim Manico
OWASP ESAPI Project Manager
http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API
 
OWASP Podcast Host/Producer
http://www.owasp.org/index.php/OWASP_Podcast
-------------- 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