This story is wrtten by hasegawa.yosuke in webappsec.jp(Japanese only blog).
It is thought that XSS using UTF-7 is occurs when charset is not specified. However, this is a biggest mistake in Internet Explorer.
Accurately, XSS occurs when not specified charset,Internet Explorer can recognized charset. Even if charset has been added, XSS is occurs when a character encoding name cannot be recognized by Internet Explorer.
For example,IE cannot correctly recognize the character encoding name to following HTML. Therefore, it is interpreted from the content of HTML as UTF-7 and the script runs. The string "utf8" in charset is not correct charset(hyphen comes off) but used commonly as "UTF-8".
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html;
charset=utf8">
</head>
<body>
+ADw-script+AD4-alert(document.location)+ADsAPA-/script+AD4-
</body>
</html>
The list of the character encoding name to be able to distinguish IE correctly is being defined in registry at "HKCR\MIME\Database\charset".The attecker could occur XSS by combining with
CVE-2007-1114 if Web Application send these character encoding name.
In the character encoding names tend to be,at the Web application in Japan,other than "utf8" example above, and the character encoding name to which IE cannot be recognized is as follows.
jis
Expression of ISO-2022-JP used commonly
MS932 / CP932 /
CP942C
Similar encoding of Shift_JIS in
Java
Windows-31J
IANA formal registration name of code page
932 used with Windows.
I think this cannot be recognized IE is bad no matter how
it thinks.
Sometimes it seen the character encoding is not only hard-coded on the Web application but the character encoding can be specified from the outside according to the parameter like below.
http://example.com/?q=abcd&charset=euc-jp
It is like converting it's character encoding according to the parameter not only is interpreted according to the specified character encoding but also the output is parameter character encoding specified.When the character encoding name such as CP932 ,above-mentioned , is allowed, XSS will be occured in such kind of Web application.
http://example.com/?q=%2BADw-script%2BAD4-alert%28document.location%29ADsAPA-/script%2BAD4-&charset=CP932
Use character encoding name without the problem such as "Shift_jis" or "UTF-8" in error pages or all pages, let's bear it in mind.
Good News.
When I(hasegawa) have submitted Microsoft as a demand of the improvement of the specification of Internet Explorer (*1), the answer was wanting i(hasegawa) to report as a vulnerability report again. Then, when reported again as a c, I got the following answers (excerpt summary).
This phenomenon is same as the content that is already public, and our
company(Microsoft) judges it is vulnerability of Internet Explorer. Our company
recognizes that the modify of this phenomenon is necessary, and is examining the
modification now.
The future, IE will be corrected to the direction to decrease.where the situation of XSS generation like the above-mentioned. It was indeed unexpected.because i(hasegawa) had not been thought that Microsoft judged such behavior of IE as a vulnerability.
*1:I(hasegawa) was thought that it did not apply to the definition of "Security vulnerability" that Microsoft meant, and assumed the demand of the specification improvement.
