RE: Extended ASCII characters used for injection

["Chris Weber" <chris () casabasecurity com>]

You're right this does boil down to requirements.  However, I would suggest
getting out of the habit of thinking in terms of 'extended character sets'
as if ASCII is the default.  UTF-8 has surpassed all other encodings on the
Web as of 2008.  That means most modern browsers are speaking UTF-8, but
being ASCII-compatible, there may never be a need for a client to send >
0x7F if all your users are English speaking, but even then there's marks and
such....  Back to your point, setup the requirements and if you know you're
application only needs to support certain scripts then setup an allow-only
rule for the specific encodings you expect, not an allow or deny rule based
on the bytes.

PS I made a type, probably obvious, which should say 'if you blocked 0x80 -
0xff'.  

-----Original Message-----
From: john s [mailto:rwnin.security () gmail com] 
Sent: Thursday, October 21, 2010 8:14 AM
To: chris () casabasecurity com; planetlevel () gmail com
Cc: Nibbler; webappsec () securityfocus com
Subject: Re: Extended ASCII characters used for injection

<snip>
> You'd be blocking legitimate usage of many different character 
> encodings including UTF-8 and ISO-8859-1 if you blocked 0x77 - 0xff.
</snip>

<snip>
> What platform are you using? It really makes a difference in how 
> Unicode is handled.
</snip>


Doesn't this issue really boil down to the requirements of a given
application?

Just because some applications require extended character sets, does that
mean every web server implementation needs to support them all?




This list is sponsored by Cenzic
--------------------------------------
Let Us Hack You. Before Hackers Do!
It's Finally Here - The Cenzic Website HealthCheck. FREE.
Request Yours Now! 
http://www.cenzic.com/2009HClaunch_Securityfocus
--------------------------------------