XSS без участия сервера - это опасно?

Question

Мы обсуждали решение для клиента на языке javascript, которое предоставляет посетителю сайта возможность аннотировать страницу для печати и использовать ее с точки зрения XSS или аналогичного вектора атаки.

Обоснование: существует потенциально длительный процесс выбора данных для отображения. Для документирования предпринятых шагов предоставляется textarea (без включения форма ), что пользователь может написать произвольный текст, который не предполагается передавать на сервер. Исходный текст является статическим, например, краткий набор инструкций по использованию этого поля, чтобы у злоумышленника не было (очевидной) возможности создать URL-адрес, содержащий вредоносный javascript для этой области текста.

Как только пользователи изменяют этот текст, они печатают страницу (и свои заметки). Заметки теряются, когда пользователь покидает страницу.

В случае «слишком большой прозаической ошибки» приведем пример кода:

<span id="descriptionHeader">Description of the result</span>
<div id="description">
  <textarea id="descriptionEditor" rows="15" cols="80" type="text"
            ondblclick="replaceDescription()">
Edit this text to add a detailed description to this page.
Double click to this editing area to finish editing.
If you want to edit the text again, do a double click to the
description header.
You may use html (e.g. <br>) for formatting.
   </textarea>
 </div>
 <script type="text/javascript">
    var header = getElem("descriptionHeader");
    var editor = getElem("descriptionEditor");
    var description = getElem("description");

    function empty() {
    }

    function editDescription() {
        header.ondblclick = empty;
        editor.value = description.innerHTML;
        description.innerHTML = "";
        description.appendChild(editor);
    }

    function replaceDescription() {
        header.ondblclick = editDescription;
        description.removeChild(editor);
        description.innerHTML = editor.value;
    }
</script>

Снова:

• Текст никогда не обрабатывается на стороне сервера, только статическое описание («как использовать») отправляется с сервера на клиент, а не с клиента на сервер.
• Пользователь может добавлять элементы javascript по своему усмотрению и эксплуатировать ад из себя.
• Я не могу придумать сценарий, в котором это создает угрозу безопасности, но тошнотворное чувство остается ...

Примечание. Вопрос не в элегантности этого решения или какой-либо библиотеки, которая делает встроенное редактирование более комфортным, а исключительно в мыслимых рисках безопасности - если таковые имеются.

Answer 1

description.innerHTML = editor.value;

Несмотря на то, что действительно относительно маловероятно, что пользователя можно убедить пойти на компромисс, введя подходящий тег , действительно ли вообще необходимо разрешить ему вводить HTML? Как насчет простого экранирования значения:

function escapeMultiline(s) {
    return s.split('&').join('&amp;').split('<').join('&lt;').split('\n').join('<br />');
};

description.innerHTML= escapeMultiline(editor.value);

Тогда пользователь мог бы с радостью набирать <символы и разрывы строк, не воспринимая их как HTML. </p>

(С аналогичным уходом на обратном пути, конечно.)

Answer 2

Возможна атака социальной инженерии: попросить пользователя (с помощью чата или чего-то еще) скопировать и вставить что-то, что должно быть красивым шаблоном для добавления на страницу.

Может показаться пользователю менее подозрительным, чем запрашивать пароль; но кроме как целенаправленной атаки, она не будет работать, так как может быть помечена довольно быстро, если размещена в публичном месте, например на форуме.

---

Я не вижу никакой автоматической атаки, так как между клиентом и сервером не передаются данные. Все атаки выполняются на стороне клиента, и кроме социальных, любая атака на стороне клиента, которая может изменить ваш DOM или вызвать javascript на вашей странице, не требует этого для выполнения XSS.

---

Обратите внимание, что при необходимости для социальной инженерии clickjacking можно использовать, используя несколько фреймов над вашим сайтом, когда ваш сайт находится в фрейме под ним, злоумышленник может скрыть тот факт, что форма на вашем сайте, но ему все еще нужно обмануть пользователя, чтобы скопировать и вставить код JavaScript в текстовое поле ввода.

---

Чтобы обезопасить ввод без потери функциональности HTML, вы можете отфильтровать HTML, перенеся код, такой как stackoverflow one , на javascript (или просто попросите лицензию на версию javascript, которая используется в живом предварительном просмотре ).

Answer 3

Не зная всего приложения. Я думаю, что можно было бы атаковать вашу систему. Если они могут видеть на других страницах некоторые допустимые вызовы js / other, они могут ввести этот код на этой странице, чтобы попытаться изменить ваши внутренние данные. Как уже говорилось, потенциально зависит от того, как вы построили свою систему.

/ Alberto