XSS without a server being involved - is this dangerous?

Question

We've been discussing about a client-only solution in javascript that provides means for a site visitor to annotate a page for printing and it's exploitability in terms of XSS or similar attack vector.

Rationale: There's a potentially long process choosing what data to display. In order to document the steps taken, a textarea (without enclosing form) is provided that the user can write arbitrary text that is not supposed to be transferred to the server. The initial text is static, e.g. a short set of instructions how to use this field, so that there is no (obvious) possibility for an attacker to construct an url containing malicious javascript for this textarea.

Once the users change this text they print the page (and their notes). The notes are lost once the user leaves the page.

In case of "too much prose error" here's some example code:

<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>

Again:

• The text is never processed server-side, only the static description ("how to use") is ever sent from the server to the client, never from client to server.
• The user may add javascript elements as they like and exploit the hell out of themselves.
• I can't think of a scenario where this will pose a security risk, but a queasy feeling stays...

Note: The question is not about the elegance of this solution or any library that does inline editing more comfortable, but purely about conceivable security risks - if any.

Answer 1

A social engineering attack is possible : Asking a user (by chat or something else) to copy-paste something supposed to be a beautiful template to add to the page.

It may look less suspicious to the user than asking for password; but except as a targeted attack it won't work as it may be flagged pretty fast if posted on a public place like a forum.

---

I don't see any automated attack as no data goes back and forth between the client and the server. All attacks are client-side, and other than social any client-side attack that could modify your DOM or call javascript on your page doesn't need this to do XSS.

---

Note that if needed for the social engineering clickjacking could be used, by using multiple iframes over your site, with your site in an iframe underneath, an attacker could hide the fact that the form is the one on your site, but they still need to trick the user to copy-paste the javascript code into the input textbox.

---

To secure the input without loosing the HTML functionallity you could filter the HTML by porting code like the stackoverflow one to javascript (Or ask nicely for a license to the javascript version that is used in the live preview).

Answer 2

description.innerHTML = editor.value;

Whilst it is indeed relatively unlikely that a user could be persuaded to compromise themselves by typing a suitable <script> tag, is it actually necessary to allow them to type HTML at all? How about simply escaping the value:

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

description.innerHTML= escapeMultiline(editor.value);

Then the user could happily type < characters and linebreaks without them being misinterpreted as HTML.

(With similar de-escaping on the way back, of course.)