Comment by Someone1234 | Hacker News Reader

Comment by Someone1234 | Hacker News Reader

Parent Full thread

If you had included just one more line of code it would have shown that this isn't a XSS issue at all:

     var products = window.localStorage.getItem('products') || [], content = '';

If an attacker can set a localStorage value then they can already run JS making this entire attack vector completely superfluous. In order for your claimed attack to work someone has to have already conducted a XSS.

It is like talking about the risks of XSS within locally set cookies. It might technically be true but how do you set the cookie in order to later run the JS taken back out of it? Same issue here. How do you set the localstorage to give you back the JS to commit XSS, more XSS?

This is going to be very app specific but 'products' might be a list of products in a shopping cart and the products can be submitted to the store by third parties with arbitrary names. Then all an attacker has to do is to trick you into adding his evil product to your cart. Alternatively, products might be some kind of client side cache of products from the server and the attacker might not even have to trick you into adding something to your cart.

Of course it could be possible that the 'name' value is HTML and not TEXT and has already been pre-escaped. :)

Regardless of whether this is exploitable XSS or not this is probably a correctness issue. Stuff shouldn't start breaking when people start inputting '<' somewhere.

It's best to just not concatenate strings and then dump them into HTML. You can't know it's not an XSS issue unless you know how this ended up in localStorage to begin with. It could be untrusted user content that came from the server. But even if you do know where it came from, just don't do it. It's a bad habit and the day it burns you it might sting.

Reply on news.ycombinator.com