>>At 12:22 PM 2/7/2002 -0500, Elliotte Rusty Harold wrote: >>In other words, it's not our fault. Blame the client software. Sounds >>distressingly like the Unicode Consortium's approach to these issues. >>Interestingly, my attack works with a single character representation >>(Unicode).
Substituting Greek for Latin works just as well with 8859-7 as with Unicode. And (as I have argued separately) it will have to work with any workable multilingual character set. For the record it's worth noting that Unicode as a rule requires additional and strong justification before encoding characters that duplicate the appearance of an existing character (but may have a different function). The reason for that is not security, but the fact that such duplication always carries with it the risk of unintentional misidentification and therefore corrupt data. Such risk is mitigated for the characters from different scripts (or different alphabets) since data entry methods (keyboards) would normally allow access for only the proper character. (If I set my keyboard to Greek, I won't get the Latin "A" by accident). Exceptions are found in some areas of punctuation. But good editing software can make the distinction visible. A security conscious browser could alert users to mixed Latin/Greek URLs in precisely the same way. A./