UTF-8 エンコーディングの危険性 - WebOS Goodies

UTF-8の非最小形式による代替エンコーディングの話。古典的な攻撃方法なので、知っていて当然の話だと思っていたのですが、意外にまだ知られていないんですね。古くは Nimda の攻撃でも利用されていました…というのを調べていたら、たまたま「セキュリティホールのアンチパターン」という資料がひっかかったので紹介しておきます。あとは、ばけらさんによる説明「用語「Unicode Web Traversal」@鳩丸ぐろっさり (用語集)」がわかりやすいです。
個人的には、「UTF-8」というからには、こういうおかしなバイト列が含まれていた時点で入力全てを捨ててしまって例外などを発生させるべきで、無理やり UTF-32 とかに直すのは間違っているように思います。そうでないと、0xC0 0x32 のように、完全に壊れている UTF-8 をどうするの？とかにもなりますし。
あと、どうでもよい話：

そもそもUTFはtransfer用encodeなんだから。

と言ってしまうと、UTF-16 だって UTF-32 だって transfer 用なのかとか思ったり。
(追記)
↑とか書いていたら、

「UTFは」を「UTF-8は」に訂正。

だそうで。
あと、やっぱりUTF-8は内部エンコーディングにはむいていないと思います。UTF-16などと比べて、US-ASCII領域で互換性がある、0x00を含まない、0x3Cや0x5CがU+003CやU+005C以外の箇所に現れないなどのメリットはありますが、それらはいずれも既存のAPIやファイルシステムやその他諸々を利用する上で「とりあえず」問題が顕著に出てこないというだけであって、それ以上のメリットはないと思います。結局は非最小形式でないかを必ず境界でチェックする必要がありますし、どんなときでも可変長なエンコーディングを意識しないといけないわけで、内部エンコーディングとして使いやすい形式ではないと思います。