* Jiri Hajek <[EMAIL PROTECTED]> [2007-05-16 14:40]:
> As for security exploits, I don't see any, Unicode 4.0 standard
> allows applications to ignore such incorrect characters.

The Unicode standard is beside the point. There is lots of code
that does not handle charsets and encodings correctly, which can
open vulnerabilities to metacharacter injection. (Examples of
this class of problem are SQL injection, XSS and format string
exploits.)

> 2. No matter how you feel about 1., there's another problem:
> SQLite fails e.g. on 0xE000 UTF-16 character, which, as far as
> I know, isn't illegal. As a different example, SQLite doesn't
> fail on 0xFFFF character, which is by definition of Unicode
> standard a 'noncharacter' and isn't allowed in open interchange
> of Unicode text data.

This is a bug and should be fixed. SQLite should accept all
correct characters and reject all incorrect ones.

> So, the upshot is, that I think SQLite should simply discard
> any Unicode 'noncharacters' in SQL statements and don't
> consider such statements as invalid.

SQLite is the wrong layer at which to address this. If an
application expects to deal with such partially corrupted data,
it should explicitly do its own scrubbing. There is code to do
this in all languages you’d care to use and many you wouldn’t.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------

Reply via email to