Limited JavaScript app scenario: Attack vectors and mitigation

Question

I'm going to be developing a single page JavaScript app which allows input via a textarea. This input is never sent to the server, never shown to another user, and will only be persisted in browser memory as long as they are on the page. Any input will need to be redisplayed to the user who has entered it.

1. What attack vectors are there in this kind of scenario?
2. What would you do to mitigate any attack vectors?

Options to me seem to be dumb JavaScript HTML encoding before adding to the DOM or simply keeping the textual input in the textarea as is and disabling it.

Answer 1

• What attack vectors are there in this kind of scenario?

DOM-based XSS is the big one.

Normally that can allow a host of things key-logging, exfiltration of data on the page, XSRF, redirection to a phishing site, drive-by-downloads.

But as long as it is only redisplayed to the user who entered it and does not persist, it's not really an issue.

• What would you do to mitigate any attack vectors?

Use document.createTextNode(plainText) to insert text into the DOM instead of node.innerHTML = plainText.

Make sure that you do not pre-populate the text box with data from the URL so that it really is true that the data is entered by the user.

Do not allow framing of your site to prevent an attacker's page from wrapping your page and socially-engineering the user into copying&pasting content into the textbox.

Answer 2

The two biggest threats are Clickjacking and accessing the offline storage. The offline storage maybe accessed with DOM Based XSS or if the machine running it has been compromised. Even if your application doesn't use GET/POST/Fragment as input, one of your libraries might.

Answer 3

Avoid client-side XSS (also known as DOM-based XSS). Read OWASP for resources on this topic. See also Adam Barth's advice on this subject, which is excellent.

A short version: for heaven's sakes, don't use setInnerHTML, document.write(), or eval() on the text the user enters into the textarea. Use setInnerText (or document.createTextNode etc.) instead of setInnerHTML.

Answer 4

Assuming no data is read from anywhere (such as GET parameters), the only possible attack is that the html document is tampered with when it's loaded. If it's loaded locally, the version on the disk may be tampered with; if it's loaded from a server without https, the document may be changed during the transfer or changed on the server.

Other than that, if there is no input or output (besides what is typed and visible on the screen; I mean things like saving to disk), I don't see what attacks you could execute that you can't on every other input field on the system.

Edit: Oh, missed this part: Any input will need to be redisplayed to the user who has entered it. The sentence before that one suggested it would be deleted. That might indeed be an attack vector, for example when that cache is tampered with. I don't think there are big risks in this though.