ア | イ | ウ | エ | オ |
カ | キ | ク | ケ | コ |
サ | シ | ス | セ | ソ |
タ | チ | ツ | テ | ト |
ナ | ニ | ヌ | ネ | ノ |
ハ | ヒ | フ | ヘ | ホ |
マ | ミ | ム | メ | モ |
ヤ | ユ | ヨ | ||
ラ | リ | ル | レ | ロ |
ワ | ヰ | ヴ | ヱ | ヲ |
ン |
A | B | C | D | E |
F | G | H | I | J |
K | L | M | N | O |
P | Q | R | S | T |
U | V | W | X | Y |
Z | 数字 | 記号 |
UTF-8で冗長な符号化を行なうことでサニタイジングをすり抜け、それによりディレクトリトラバーサルを行なう方法。
UTF-8はその仕様上、同じ文字を異なる符号列で表現できてしまう。
例えばASCIIの0x2F('/' スラッシュ)は、「0xC0 0xAF」「0xE0 0x80 0xAF」「0xF0 0x80 0x80 0xAF」でも表現できる。これらはUTF-8において違反であり、これらの符号列は無視されなければならないが、Nimdaワームが登場した当時は、明確な対応が明示されていなかった。
このため、この問題を適切に処理しないまま0x2Fだけをサニタイジングすると、ディレクトリトラバーサルで使われる "../.." のような文字列を通してしまう盲点を生むことになる。
外部から読み込まれたUTF-8を、そのまま加工せずに使う、完全なUTF-8処理系の場合、あまり問題になることはないと思われてはいる。
しかし、このUTF-8文字列を別の形式に変換するような場合、問題が生じる可能性がある。
IISについては実装の甘さが露呈したことは疑いようが無いが、現実にはIISに限ったことではない。
UTF-8には、このような仕様上の欠陥があるため、文字列の扱いには注意を払わないと、現在でも、今後も、この手のバグを作りんでしまう可能性が高い。RFC 2279にもこの問題に対して注意を勧告する記述がある。
コメントなどを投稿するフォームは、日本語対応時のみ表示されます