0

I'm designing an authentication system that stores some hashed strings as "tokens" on the client machine

localStorage['tokens'] = [username, string1, string2, .... ]

and also associates those tokens with a row in a database table

____________________________________
| Table: current_user_sessions     |
------------------------------------
| username | token1 | token2 | ... |

so that any time a user tries complete an action, the client machine queries the database asking for a row with those matched tokens and the user's name to verify that the user is logged in a valid session.

I send these tokens as variables to the php page that checks to make sure the session is valid.

$tokens = $_GET['tokens']
$session_is_valid = query_that_checks_db_for_tokens($tokens)
return $session_is_valid

Is it possible for someone to get access to another user's localStorage through an XSS attack and is this an unsafe way to keep a user session secure?

kjh
  • 3,407
  • 8
  • 42
  • 79

3 Answers3

2

Your browser protects local storage using the same origin policy, so Javascript code running on a page hosted at http://a.com cannot access local storage stored by Javascript code running on a page at http://b.com. If your webpage has an XSS vulnerability and people can inject Javascript code into it, they can access your local storage.

With that being said, your scheme seems reasonable. Spending a little bit of time to make sure that your page doesn't have any XSS vulnerabilities seems like a good use of time.

Sam King
  • 113
  • 6
1

The main problem with this approach is that local storage is vulnerable to XSS since it is accessable via JavaScript (of course, having a page which is vulnerable to XSS is a problem in of itself). If your tokes are small enough to fit in a cookie, then that is the best place to put them.

If you set the HTTP-only flag on a cookie, the browser will not allow JavaScript to access it. If you set the Secure flag on a cookie, the browser will only send it with HTTPS requests. If you are sending security related tokens, you should probably be using both flags.

Aurand
  • 5,487
  • 1
  • 25
  • 35
  • What if it doesn't fit into a cookie ? You have no choice other than db and make sure your input is safe as I mentioned in my answer. – jayadev Oct 20 '13 at 16:45
  • @jayadev If it doesn't fit in a cookie it's going to be insecure. The OP is asking if local storage is secure. The answer is no. There generally isn't a good argument for storing more **secure** data client side than can be put in a cookie. – Aurand Oct 21 '13 at 17:48
-1

You should use cookies if the user data is small (or can be compressed) and fits into a user cookie. That avoids the need for local storage and the security issues that come with it.

If that is not the case then you are forced to use a local/centralized storage, the main items you should be careful is sql injection when you read tokens from http parameters and directly use in mysql queries. Typically mysql_real_escape_string or parametrized queries are used to prevent this (details here). You also should escape your input to prevent XSS independent of your session storage strategy.

Some details to be aware of :

  • User name is a unique identifier (some sort of guid).
  • A faster way typically used for storing session is using memcached cluster for session data.
  • Be aware of Cross side request forgery and use crumbs since you are updating user data.
Community
  • 1
  • 1
jayadev
  • 3,576
  • 25
  • 13
  • I would assert that it is, infact, unsafe. The OP asked if XSS can be used to steal auth tokens stored in local storage and it can. – Aurand Oct 20 '13 at 05:17
  • Well browsing internet in your computer is potentially unsafe but the solution is not to stop browsing :). As I mentioned in my solution if you can use cookies of course you should, but looking at the schema and amount of data I assume the data is big, or he might have already considered cookie. Then there is no choice other than to use a central storage like a db. The solution is to make sure you inputs are clean. – jayadev Oct 20 '13 at 16:44