What are all the methods to delete local-storage data?

956 views Asked by At

My core question is what are the possible methods to delete window.localStorage data (not window.sessionStorage) from the client's browser. One way that I know is by going to the client's console and type localStorage.clear().


I'm building a web app that uses HTML-local-storage to replace PHP sessions and cookies.

I have a web app that does the following:

  1. User requests a web page from the server
  2. Server responses a page with JavaScript to remove client's local-storage data(email and password) The password is actually a GUID string.
  3. The JavaScript script then sends as a post-request with the email and password to the Server. The email and password variables could be empty if the user is new or may contain values if the user is a returning user.
  4. The server checks if user exists or doesn't exist.
  5. If user does not exist, then server sends the login page
  6. If user exists, then server sends the requested page
  7. Once the user is good to go, every time the user requests any web-page from the web server two things happens: 1)Every time the user requests a page, the request will contain the user's local storage data (email and password) 2) Every time the user requests a page, the server does a query to the database to check if user exists.

My questions are: 1) What are the security issues 2) Is there are a better way? I don't want to use Sessions or cookies.

1

There are 1 answers

0
Brad On BEST ANSWER

I'm building a web app that uses HTML-local-storage to replace PHP sessions and cookies.

Local storage is a solution aimed at replacing neither. Local storage is for storing data client-side. Cookies are for identifying clients at the HTTP level. PHP sessions are meant for storing data server-side, usually keyed by a cookie.

The password is actually a GUID string.

GUIDs are not really random. Depending on the algorithm used, part of the GUID is the MAC address of the server generating. Next, the timestamp is also used. You're left with not much entropy. See also: Are GUIDs good passwords?

The JavaScript script then sends as a post-request with the email and password to the Server. ...

Every time the user requests a page, the request will contain the user's local storage data (email and password)

The thing with sending the password over the wire like this is is that you are giving attackers a predictable and frequent passing of the credentials. At a minimum, this has to be done over a secure channel (HTTPS). At that point though, your security isn't terrible.

The trick will be preventing others from accessing the local storage. Be very aware of what scripts you include on your page. (If you include some analytics or ad script for example, it will have access to that local storage data.)

And again, use HTTPS to prevent people from fiddling with the page in-transit.

A better way would be to use sessions with a rotating session ID. The "password" becomes the session ID and it changes for each request. This is much more secure than expecting a weak password from a user which rarely changes. The actual user's username and password are only sent over the wire once.