Из 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, которые являются первыми байтами трехбайтовых последовательностей, вместе со следующей цитатой и одним пробелом будут считаться значением параметра NOTEXIST.
По существу, определенные байты указывают начало 3-байтового символа в строке UTF-8. Если эти байты пробиваются на веб-страницу, IE будет потреблять следующие два байта, даже если полученные три байта не образуют действительного символа UTF-8. Это может привести к тому, что IE съедает конечные кавычки в атрибутах HTML, разрушая хаос XSS.
В статье рассказывается об IE6, поэтому у меня есть два тесно связанных вопроса:
- Это еще проблема в более поздних версиях IE?
- Если да, существует ли на стороне клиента способ избежать этого? Другими словами, если предположить, что с сервера получена "отравленная" строка, есть ли что-то, что можно сделать на стороне клиента, чтобы предотвратить эту уязвимость?
