GDPR Compliance: Does this apply to JavaScript Web Storage? - javascript

As far as I can see the main issue with GDPR and cookies is that cookies may be tracked and the data may be shared against user’s wishes.
The JavaScript Web Storage API is a useful repository for settings and other user data, but this doesn’t leave the browser.
Would using Web Storage require user permissions?

Any data related to the user is under control by GDPR.
You should ask the user for that.

Related

How do I comply with GDPR on a website using cookies and local storage?

I would like to use cookies and local storage on my website is there anything I need to do to comply with GDPR in the EU.
I know about cookie banners but I don't know if that is what I should be using for local storage.
I'm going to be using them to identify users that are logged in.
What sort of things do I need on my website, and what should the message say, stop using my website if you do not give consent to use cookies? Cookies may be stored on your device if you use this website?
Thanks to anyone who answers.
If you use cookies or local storage for essential functionality, such as sessions for logging users in, you do not have to put up any banners and such.
Specifically, cookies for login sessions are often used as an example of "technical cookies" that can be used without consent.
However, if you use those cookies, for example, to track your users or collect any data whatsoever for other then non-essential purposes (sharing them with others, marketing, ...), you need to get consent from those users and provide the option to withdraw that consent.

Is it possible to session hijack / cookie hijack / spoof a user’s session with an electron app?

I am currently evaluating the security risks for an electron app I am working on, with regards to whether it is possible to copy a file, or bunch of files stored on the user’s hard drive by electron, and just paste them into another installation on another machine and thus automatically be logged into the application using the session of the user who was logged in on the first machine. We use token auth in our app.
I noticed that electron stores its cache in a particular folder as mentioned here How to clear the cache data in Electron(atom shell)?.
Among those files I noticed a 'Cookies' file which seems to be an sqliteDB. When you open this with an sqlite db reader you can view the cookie data as plain text. However this doesn’t seem to contain the auth cookie of the currently logged in user.
Hence some of the questions I’m hoping to get answers to are:
When we log a user in the user’s auth token is stored in a cookie. Is this cookie stored in a particular file on the hard drive by electron which can be copied into another machine to spoof/hijack a user’s session?
If the answer to question 1 is yes is there a way to prevent this?
I am not a pro on security, so forgive me if I've gotten some security terminology wrong.

Where to store settings in chrome extension app

I am new to web development. I am writing google chrome extension that connects to some API. I have one page for user's settings with fields like API key, and more stuff that user want's to configure.
My question as a developer where and how should I save this settings, I thought creating a json file that it would be possible to export the file and import settings file.
Should the server save this settings? should I save it on user's machine? any suggestions?
I think it will be better if you allow user to save on their machine, it's safer and your users have to take all responsibility to keep it safe.
You can use Extension Options to provide a UI for your users to save their credentials. And in that option page, you should use chrome.storage API to store the credentials so that whenever user access to option page, their credentials still there. Later on, when you want to use user credentials to send API, just use chrome.storage API to query the credential.

Is it safe to store a sensitive data in Local Stoarge or session storage? Localstorage allows to any attacks for sensitive data

In web application , How secure is local storage in Html5 or else is there any other way to secure the sensitive data in local storage.
Project Structure:
Front End: Html5,Angular js, Middletier: Asp.net webApi , BackEnd :Sql Server.
Once user login into the page, that credentials is encrypted by using some cryptography algorithms.It will be stored in db.
After that every child action like products list, order details, book history ,add product need to validate that.
While refresh after the page, data gets lossed so need to persist the data so i have choose localstorage. stored the username and password encrypted using some js algorithms and in put in local storage.
I feel it as not safe , because of any one can steal the data from the browser tools.
Is there any alternative approach in this scenario or else this approach is secure.
can anyone help me to process.
There is something that every Webapp Craftsman must know:
There is no repository beyond your firewall that can be fully secure. Why? Because the open door that you NEED to allow your application manipulate the data is accessible to everyone.
Imagine that you decide to encrypt the content of the local storage.
This will prevent someone with access to the browser's local storage (e.g. the developer tool) to be able to read/write the data. But how your application will access the data? You have two options:
Send the encryption algorithm + passphrase within the client-side app. This will expose all your data if someone manage to read the code of your app and access to memory of the browser (e.g. the developer tool)
Send every data from the client-side to the server to be decrypted there. Well ... this is pointless. Is better to store the data in the server for that matter.
You can try as much as you want, you will need an open door, and that open door can be use by anyone.
But I've a question for you: Do you really need a fully secure repository in the client side? This kind of repository weren't created for be fully secure, but they are secure enough!
For example, the session cookie of your web app is stored by the browser right? And if someone steal that cookie, it can impersonate the user and your application will never notice it, right? This is pretty scary when you think about it.
Nowadays nobody put to much thinking on this because browsers are secure enough to protect cookies from malicious access. And of course, they did the same to protect the local local/session storage, IndexedDB, WebSQL, etc.
So, if your data is more precious than your user session, keep it in the server. If not, go ahead and put it in the browser.
PRO TIP: Consider encryption when storing in a no secure repository to make it harder to get. But remember that this comes at a price: you will not be able to use the query system of those repositories to search over encrypted data.

Fetch data from a website after login, client side

I would like to import data that the user had entered into his profile on a website that I do not control. I don't want the user to hand me his login credentials to grab the data from the server-side (connecting directly to aforementioned website). I would rather prefer the login data to stay on the client's machine: It makes my service more trustworthy and I don't have to process sensitive data.
I thought that this can probably done with javascript without greater hassle. However, given the security risks, it seems to be blocked by browsers. See How to get data with JavaScript from another server?
So I think my question is already answered and can be closed/deleted.
I'm not sure I understand what you're trying to do, but there is no secure way to verify login credentials in a browser client. If you want to check login credentials, you will have to involve a server.
Some data can be stored on the client side, but then a user is tied to a particular browser on a particular computer and can't use the service from anywhere else. In older browsers data is generally limited to what can be stored in a cookie and cookies are not guaranteed to survive for any particular long lasting time frame. In the latest browsers, data can be stored in HTML5 local storage which allows for a little more structured way of storing data, but even then you're still stuck in one particular browser on one particular computer.
Based on your comments, it sounds you're trying to "cache" a copy of the data from web-site A that you can access from client-side code on web-site B on multiple visits to your website. If that's the case, then it sounds like HTML5 local storage may work to serve as a cache storage mechanism. You will have to figure out how to get the data from web-site A into the cache as the cache will be subject to same-origin access (domain X can only access the data that was put into HTML5 local storage by domain X), but if you can get manage to get the data from web-site A into your web-site B client-side page (perhaps using JSONP), then you could cache it using HTML5 local storage. You will need to realize that even HTML5 local storage is not guaranteed forever (so you need to be able to fetch it again from web-site A if required).
You said this
I don't want the user to hand me his login credentials to grab the
data from the server-side (connecting directly to aforementioned
website).
If you do that, anyone would be able to access any User's data, since you don't restrict access to data.
You also said this
I would rather prefer the login data to stay on the client's machine:
It makes my service more trustworthy and I don't have to process
sensitive data.
I'm really not sure that's a good idea. You still need to lock down personal information. But anyway, if you really want to, you can use localstorage -- modern webbrowsers support this.
Check out this link for a primer on local storage.
Storing Objects in HTML5 localStorage
Note that the user can clear the browsers local storage, so you still need to have a form to enter credentials.
EDIT -- if you want to save a user's profile information on the client, you can do that with local storage. But you still need to save the data to the server, else if the user goes to a different machine or even browser, they won't have their data. Plus, your server side model probably needs to associate a user's content with their profile in some way. I don't think there is any way around it.

Categories

Resources