SecuriTeam - Java Runtime UTF-8 Decoder Smuggling Vector（情報元のブックマーク数）
よくわからんが、Java RuntimeにUTF-8デコードの問題があって脆弱とか？！よくわからん
That said, the underlying vector for this vulnerability identified by Rowe is actually within the UTF-8 charset implementation of the java.nio.charset.CharsetDecoder. The onMaformedInput CodingErrorAction is not triggered by the presence of overlong utf-8 octet sequences in a number of vulnerable Java runtime implementations, including Sun's JRE, OpenJDK, HP's RTE, BEA's JRocket, IBM's SDK, Apple's SDK and Apache Harmony. Other implementations were not tested.
Java Runtime UTF-8 Decoder Smuggling Vector
URIのデコード関連みたいかな？
Limiting consideration for the moment to the original vulnerability report and the HTTP/1.1 URI syntax, it becomes immediately clear that; HTTP/1.1 does not specify an encoding for the URI (RFC 2616 [13] and RFC 2396 [14]) and treats it as a octet stream known to the client and origin server, and otherwise transparent to intervening proxies. Specific characters in the HTTP URI are significant, all of them within the US-ASCII character set (which is a deliberate subset of UTF-8 and the first 128 code points of Unicode). Many implementers and applications use UTF-8 encoding for their URI patterns as permitted (but not required) by HTTP/1.1.
Java Runtime UTF-8 Decoder Smuggling Vector
However, high octets have no specific meaning within RFC 2616 or RFC 2396. Their presence, mapping two or more high octet bytes into a US-ASCII code point, must be ignored by proxies, as such bytes are entirely appropriate in other character sets and HTTP/1.1 does not attribute any UTF-8 properties to this string. Non-conforming implementations which treat the entire URI as UTF-8, and which suffer from decoding overlong octet sequences into the US-ASCII range, will behave differently than their conforming cousins.
