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> 

снова:

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

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

Answer 1

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

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

---

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

---

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

---

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

Answer 2

описание.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.

(с подобным де-спасаясь на обратном пути, конечно.)

Answer 3

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

/Alberto