7

I read that localstorage is susceptible to XSS attacks.

I currently store JSON Web Token (JWT) in localstorage, and I access and display data about the user through localstorage:

var localstore = // localStorage object

// On user login, server responds with token, store the token on client!
localstore.store(jwt_token);

// later, grab some data out of token
var name = localStore.getName();

And at some point I render some user information on the DOM with:

<span> Welcome to your profile page! </span>
<span> How are you, {{ name }} </span>

So basically:

  • On login, store token on client in localStorage
  • Access localStorage and render directly to DOM

Does that workflow contain a XSS vector? Is this fine? I have other ideas if it's not:

(1) Would a better solution be to:

  • On login, store token on client in localStorage
  • Whenever I need to display user info, grab token from localStorage and use it to query the server directly for user info

  • client gets user data, render it in DOM

    ie, 

    // prepare jwt to be sent to server
http.setAuthenticationBearer(localstore.retrieveToken());

// Request user data with jwt! 
http.get('/profile').success( function(data) {
    var name = data['name'];
    // render 'name' in DOM
}

CONS: Have to make a request to the server each time I need user data. Not ideal.

(2) Or this:

  • On login, store token on client in localStorage

  • Access localStorage, pipe data to sanitizer, render directly to DOM

    ie, <span> How are you, {{ sanitize(name) }} </span>

PROs: Simple fix to original, clean and does not have to make requests to server.

CONs: Have to remember each time to pipe data to sanitize(). Can be easy to forget. But I feel it's better than having to make requests each time like in (1)

rublex
  • 171
  • 3
  • You do not control local storage necessary so unauthorized modification is a potential threat. If another script, browser plugin, etc changes the input stored it could be modified. You may want to start with the OWASP resources on "DOM based xss (type o)" https://www.owasp.org/index.php/DOM_Based_XSS – Eric G May 11 '15 at 02:13

1 Answers1

1

Encoding / Decoding coupled with XSS sanitation pre save and pre dom render is best practice.

Mitigation strategies regarding browser DOM XSS attacks vary but can be strengthened with header options found here (https://www.owasp.org/index.php/List_of_useful_HTTP_headers).

While zero day vulnerabilities may exist in the various browser rendering engines these can help prevent unknown flaws in same origin restrictions which are the primary cause of XSS attack vectors.

Security is creating enough hoops to prevent the majority of attacks, monitoring for abnormalities and keeping systems and code bases patched is the remainder.

jas-
  • 931
  • 5
  • 9