本当は怖い文字コードの話：第4回 UTF-8の冗長なエンコード｜gihyo.jp … 技術評論社（情報元のブックマーク数）

id:hasegawayosukeキタ━━━━(゜∀゜)━━━━ッ!!<3!!!

冗長なUTF-8エンコード、、、

冗長なエンコードとは

先に述べたとおり，UTF-8ではU＋0000からU＋007Fまでの範囲の文字はUS-ASCIIと互換を持ち，0x00〜0x7Fとなりますので，多くのOSでのパス区切り記号として使われる「/」（U＋002F）は0x2Fとなります。
ところが，これを表1のU＋0000〜U＋007F以外の欄に無理やり当てはめて，1バイト以外の形式で表現することができてしまいます

第4回 UTF-8の冗長なエンコード：本当は怖い文字コードの話｜gihyo.jp … 技術評論社

Nimdaウイルス！！！そういえばUTF-8の冗長使っていたな・・・

これまでにこのUTF-8の冗長なエンコードの問題の影響をもっとも大きく受けたのは，おそらく2001年のNimdaウイルスによる被害のときでしょう。Nimdaウイルスは複数の感染経路を持っていましたが，そのうちの1つがIISの冗長なUTF-8のリクエストによるパストラバーサル（実際には，当時すでにMS00-057というパッチが提供されていましたが）でした。

第4回 UTF-8の冗長なエンコード：本当は怖い文字コードの話｜gihyo.jp … 技術評論社

やっぱり、自前のものは使わないってのは基本か。。。。

現在のほとんどのOSやライブラリ，フレームワークなどのミドルウェアでは，このような冗長なUTF-8表現は禁止されていると考えられます。そのため，冗長なUTF-8による検査の漏れを防ぐもっとも最善の方法は，UTF-8の検査や他の符号化形式への変換をライブラリやフレームワークに任せ，「自前でUTF-8を処理しない」ということに尽きます。

第4回 UTF-8の冗長なエンコード：本当は怖い文字コードの話｜gihyo.jp … 技術評論社