I know there has been a lot of discussion on the evils vs. the good of local storage. There have also been Chrome hacks for disabling a user's/visitor's ability to run JavaScript from the console which have had limited success.
None of these have addressed my question: can you prevent a user from editing local storage values in their browser?
This will never be the ideal or permanent solution to a current issue, I just need a way to do this until we can refactor the codebase to use IndexedDB.
EDIT: There is no sensitive data being handled in local storage for this app which is only available to local users on an in-house network. There are some data points that a handful of users have learned can be edited and it is these users the project owner is concerned about.
No, you can't. Even if there is a temporary 'solution' or hack that seems to work, it is still the web, so there is no way to prevent access to it. Trying to prevent a user from accessing a resource on their own system is doomed to fail.
Methods I can think of inside and outside the browser to read from and write to the local storage:
Inject JavaScript in the page to read the local storage;
Create your own browser or browser plug-in;
Read the SQLite databases in %LocalAppData%\Google\Chrome\User Data\Default\Local Storage.
You cannot do this. There is no way to control a user's browser in this way, and there should never be. That is antithetical to the nature of the Internet. Your server publishes code. People consume that code using some kind of browser. That's it. You have no control over what reads your code or what it does with the code once you've served it up.
Your approach to security is completely wrong. You cannot secure this on the client's side.
It's up to you to use localStorage securely from the get-go. That means you cannot trust any data stored there, and you cannot store anything there that you don't want the user to read. There, or in cookies, or in IndexedDB, or in any client-side data store. Security comes from inherently mistrusting any user-submitted data. You need to validate any and all data that a user sends to your server, full stop. Trying to prevent them from changing the data cannot work, because they can just write their own data. They can produce a request that will send literally anything to your server.
If you're storing sensitive data in localStorage or any other client-side data storage, you're doing it completely wrong, and you need to abandon that approach, because it cannot be salvaged.
Related
As an example I have a Vue.js application. When the app is loaded, I fetch some sensitive data from the server over HTTPS and store it in the Vuex Store client side.
Is there any way someone can read that data via the Developer Tools in the browser or some other way? Is it safe? Is there any way for someone to write to the Vuex Store in the same manner?
Is there any way someone can read that data via the Developer Tools in the browser or some other way?
Yes. All you need is a reference to a Vue component, then you can access its $store property.
In dev tools, select an element in the DOM corresponding to a Vue component. Then in the console, enter:
$0.__vue__.$store
and you have access to the Vuex store. $0 corresponds to the selected DOM element.
In general, you should always assume that all client-side data can be accessible by the user in one way or another. There may be ways you can "hide" this data, or make it more difficult to access.
The developer console can be considered part of the application in this regard. Anything you could do in code can be done on the console as well. If your app can access something, so can the user.
And it's even worse than that. Even if your user doesn't care about client-side stores, because it's his data anyway, if your app is vulnerable to XSS, a malicious user exploiting it can also access any data in client-side stores.
In addition to that, if you store something on the client, it may get written to disk (cookies, websql, and so on). So if the attacker has access to the client PC even outside the context of the application, he will also be able to access such data.
So in short, simply don't persist sensitive data on the client.
Is there any way to store persistent data for Chrome Extensions without using a web server?
Is Chrome storage persistent? https://developer.chrome.com/apps/storage
I want to avoid the costs of a server, but I also don't think localStorage is good enough because the user can delete it.
In fact, the only persistent data I need to store is the accounts that have logged into the extension on the device itself, so that info might be stored by Google's servers already?
I don`t think there is an non-server way to store extension data without user being able to modify it.
However there are lot of great services that offer free plans for many platforms eg. Heroku
Say, I have a website DomainA.com which uses java script file from DomainB.com. Now, when a user does some action i need to store data which i can access from DomainB.com, so i started to set cookies from the javascript file loaded from domainB.com, the cookies are stored in the domainA.com instead of domainB.com.
I am restricted to use javascript to store the data using client side storage like cookies or local storage, How should i approach to store the data on domainB.com in this scenario?
If you only have access to JS (not Flash, Silverlight, Java, et cetera), and you have no access at all to server-side storage procedures, then there really isn't any way to store and retrieve data on one domain, intended for another domain.
That's by design.
What you're currently asking for would be very helpful for making life easier for developers, but it would also make life very easy for everyone from hackers to data-miners who could just save everything you're doing in a spot set aside from their domain, and then the next time you're on their domain (an ad, running injected JS, perhaps), they can just grab all of that data from all sites you've been on...
Not great.
It's not that preventing this behaviour solves the problem of injected scripts stealing your data, on poorly-secured sites, et cetera, so much as allowing the behaviour makes it unfairly easy to do, and impossible to protect against.
if you write data to local storage with javascript on Android like this:
localStorage.data = "test";
Can this data be access and viewed in some way? I have some important data to save like user personal information and I would not like for anybody to see this data (even if they put some effort in this). Solutions?
There aren't protected at all if you have access to the browser.
Anybody connecting to your site from the user's browser can simply type console.log(localStorage) in the developer's tools (use Ctrl-uppercase-i on most browsers) to see it in clear.
A solution might be to encrypt the data using a server provided key, but this wouldn't be so secure : it's easy (for example using an extension) to change the executed javascript once you get access to the browser (and you have the user to come back to the site). I'd suggest to store on the server those data.
I assume you are talking about a technical exploit rather than someone physically getting hold of the actual device?
If so, it is my understanding that only code on the domain from which the data was saved can access it. So you'd potentially be vulnerable is someone managed a XSS attack or you incorrectly included someone else's script.
I'm trying to develop a cross platform application, where the most obvious route would be a web site with JavaScript, but then I lose the cosy comforts I'm used to using in my C# desktop apps, like file system access etc. How do I go about accessing similar services from within the browser?
E.g. I don't need to access anything I don't create, so actual file system access is just a luxury. I can use whatever the browser offers for offline storage, but have no clue how to do this.
Depending what you need to store you could possibly use a cookie.
For larger storage this is what the upcoming HTML5 client-side storage methods address, but we're not quite there yet.
Security concerns prevent browsers from getting real access to storing things client-side for the most part, though.
Have a look at Google Gears.
For simple file manipulation, why not use a well established protocol like FTP?
It's accessible both from browsers and from code.
If you're encountering firewall/security/permissions concerns, you can always use HTTP.
It all depends on how you access your storage.