Из hi.baidu.com/monyer/blog/item/d0f5d8b48fc442758bd4b2a4.html
Char 192 равен <font face="xyz[0xC0]">not </font><font face=" onmouseover=alert(192) s=[0xC0]" >available</font>
0xC0 - это один из 32 первых байтов 2-байтовые последовательности (0xC0-0xDF) в UTF-8.Поэтому, когда IE анализирует приведенный выше код, он будет рассматривать 0xC0 и следующую кавычку как последовательность, и поэтому эти две пары элементов FONT станут одной с "xyz[0xC0]">not </font><font face="
в качестве значения параметра FACE.Второй 0xC0 запустит другую 2-байтовую последовательность как значение параметра NOTEXIST, который не заключен в кавычки.Из-за пробела, следующего за кавычкой, 0xE0-0xEF, которые являются первыми байтами 3-байтовых последовательностей, вместе со следующей кавычкой и одним пробелом будут рассматриваться как значение параметра NOTEXIST.
По существу, определенные байты указывают начало 3-байтового символа в строке UTF-8.Если эти байты попадут на веб-страницу, IE сожрет следующие два байта , даже если полученные три байта не составят действительный символ UTF-8 .Это может привести к тому, что IE израсходует конечные кавычки в атрибутах HTML, что приведет к хаосу со вкусом XSS.
Статья посвящена IE6, поэтому у меня есть два тесно связанных вопроса:
- это все еще проблема в более поздних версиях IE?
- Если это так, существует ли чисто клиентский способ избежать этого?Другими словами, при условии, что с сервера получена «отравленная» строка, можно ли что-нибудь сделать на стороне клиента, чтобы предотвратить эту уязвимость?