CODEWITHSUNDEEP
javascriptsecurityxss
Olaf Kock
Olaf Kock

Reputation: 48077

XSS without a server being involved - is this dangerous?

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:

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.

Upvotes: 1

Views: 619

Answers (3)

nan
nan

Reputation: 37

Not knowing the whole application. I think it would be possible to attack your system. If they can see from another pages some valid js/other calls, they could inject that code in this page to try to alter your back-end data. As said, potentially depending on how you built your system.

/Alberto

Upvotes: 0

Julien Roncaglia
Julien Roncaglia

Reputation: 17837

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

Upvotes: 2

bobince
bobince

Reputation: 536567

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

Upvotes: 2

Related Questions