I have developed web application that will store user's profile sensitive data in index db and local storage.I am using web storage as i need to access this data frequently in contacts page,chat page and other places as well.
My main concern is that everyone who is loggedin has access to this sensitive data.
So i was searching around ways to either block access of indexDb and Local Storage,I also check this Stack Overflow Question: Can local storage ever be considered secure? but could not make out proper decision to opt for.
Then i was wondering if we can encrypt this data while saving and decrypt after fetching so that no one has direct access to it.
Can any one suggest any approach and methodology which can easily solve my problem.
Thanks in advance.
After exploring a lot i found YDN-DB(Unified data access layer on IndexedDB, WebDatabase and WebStorage storage mechanisms) but i am yet to implement it,can anyone suggest any better solution than YDN-DB or its the best i can opt for now.
https://dev.yathit.com/ydn-db/index.html
Details of this DB can be checked in the above link.
Related
I am still new to solo-writing a back-end to my app so I have some concerns,
the concern I am asking about here is a security concern about sharing my database structur in the client app,
As it is known all code that is written on client side is "not safe from interested clients",
I read this medium post by Doug Stevenson from the firebase team,
What I am looking for exactly is an answer to the title of my question (which is the same title as the post on medium):
Should I query my Firebase database directly, or use Cloud Functions?
but I didn't really get an answer as he said that it depends on the situation and requirements of my app,
So can anyone tell me if it is ok,from a security perspective, to do direct queries on the client side that expose the structure of data in my database (firestore), or should I use instead only cloud functions for this?
notes:
I am aware that real-time data can only be achieved using client-sdks and thus I should give up that feature if I don't want to share my database structure in the client app
Allowing direct client access is as safe as you choose to make it.
There's nothing about the structure of data that's not secure. Your implementation lacks security only if users are able to do things that you didn't intend for them to do. That's entirely up to you to implement with security rules. If your rules accurately express what users should and should not be able to do, you will have no problem. If you are unable to use security rules to meet your needs, then you should force access through a backend.
I'm still learning how to implement realm.io in my next project. I'm really amazed in the Realm Mobile Platform (offline-sync).
I'm reading https://realm.io/docs/realm-object-server/#access-control but what I need is preventing user accessing certain data in a model. (let's say they only can access data only their own data).
Thank You
In addition to the Realm documentation. There are a couple overviews on Multi-Realm setups you could check out. They go over permissions and database design.
https://realm.io/docs/tech-notes/multi-realm-cheatsheet/
https://realm.io/docs/tech-notes/teamwork/
i am implementing a chat system in asp.net, much like google chat and i use xmhttp to send and receive data, and i am using a single table to store all chat for all user.
i wanted to create global temporary tables in sql using a XMLHttpRequest so as to be abl to organise data better(instead of storing all the chat in a sigle table which can(i dont know for sure) cause locking issues when many users are accessing it.)
also for my system i don't have to store the chat and so i thought that a global temporary table would be better since it will already be dropped and save me the trouble of clearing it.
but the after the table has been created by the Xmlhttprequest it gets dropped just after its creation....why this happen i don't know....i also have removed all connection closing lines but still no luck
so what should i do?? also if anyone knows of any online resources that can points me about best practices to follow please tell me.
Your table won't have locking issues with many users accessing it. Temporary tables are not meant to be shared cross-call, and you're going to wind up with far more roadblocks down that path. It is probably better to simply store your data in a table, then poll the table.
The only time you could have "locking issues" is if the users are attempting to write the same chunk of data to the same row at the same time ... which shouldn't be happening in a chat application.
Additionally, Google Chat uses a COMET style implementation instead of a polling implementation. It has been my experience that COMET > polling in terms of user experience.
You're not supposed to keep any chat messages on your database actually... unless you're implementing offline messages.
My company is building an ASP.NET HR application and we have decided to create one database per client. This ensures that clients cannot accidentally view another client's data, while also allowing for easy scalability (among other benefits, already discussed here).
My question is - what is the best way to handle security and data access in such a scenario? My intent is to use a common login/account database that will direct the user to the correct server/database. This common database would also contain the application features that each user/role has access.
I was not planning to put any user information in each individual client database, but others on my team feel that the lack of security on each database is a huge hole (but they cannot articulate how duplicating the common access logic would be useful).
Am I missing something? Should we add an extra layer of security/authentication at the client database level?
Update:
One of the reasons my team felt dual user management was necessary is due to access control. All users have a default role (e.g. Admin, Minimal Access, Power User, etc.), but client admins will be able to refine permissions for users with access to their database. To me it still seems feasible for this to be in a central database, but my team doesn't agree. Thoughts?
We have a SaaS solution that uses the one DB per client model. We have a common "Security" database too. However, we store all user information in the individual client databases.
When the user logs into the system they tell us three pieces of information, username, password and client-id. The client-id is used to lookup their home database in the "security" database, and then the code connects to their home database to check their username/password. This way a client is totally self-contained within their database. Of course you need some piece of information beyond username to determine their home database. Could be our client-id approach, or could be the domain-name requested if you're using the sub-domain per client approach.
The advantage here is that you can move "client" databases around w/out having to keep them synced up with the security database. Plus you don't need to deal w/cross-db joins when you're trying to lookup user information.
Update: In response to your update... One of the advantages to each customer having their own DB is also the ability to restore a customer if they really need it. If you've split the customer's data into two databases how do you restore it? Also, again, you'll need to worry about cross-db data access if the users are defined in a DB other than the home DB.
I've always been of the opinion that security should be enforced at the application level, not the database level. With that said, I see no problem with your intended approach. Managing accounts and roles through a central database makes the application more maintainable in the long run.
You may want to look into using the ASP.NET membership provider for handling the authentication plumbing. That would work with your stated approach and you can still keep all of the authentication data in a separate database. However, I agree with Chris that keeping one DB will utlimately be more maintainable.
I am looking for a best practice for End to End Authentication for internal Web Applications to the Database layer.
The most common scenario I have seen is to use a single SQL account with the permissions set to what is required by the application. This account is used by all application calls. Then when people require access over the database via query tools or such a separate Group is created with the query access and people are given access to that group.
The other scenario I have seen is to use complete Windows Authentication End to End. So the users themselves are added to groups which have all the permissions set so the user is able to update and change outside the parameters of the application. This normally involves securing people down to the appropriate stored procedures so they aren't updating the tables directly.
The first scenario seems relatively easily to maintain but raises concerns if there is a security hole in the application then the whole database is compromised.
The second scenario seems more secure but has the opposite concern of having to much business logic in stored procedures on the database. This seems to limit the use of the some really cool technologies like Nhibernate and LINQ. However in this day and age where people can use data in so many different ways we don't foresee e.g. mash-ups etc is this the best approach.
Dale - That's it exactly. If you want to provide access to the underlying data store to those users then do it via services. And in my experience, it is those experienced computer users coming out of Uni/College that damage things the most. As the saying goes, they know just enough to be dangerous.
If they want to automate part of their job, and they can display they have the requisite knowledge, then go ahead, grant their domain account access to the backend. That way anything they do via their little VBA automation is tied to their account and you know exactly who to go look at when the data gets hosed.
My basic point is that the database is the proverbial holy grail of the application. You want as few fingers in that particular pie as possible.
As a consultant, whenever I hear that someone has allowed normal users into the database, my eyes light up because I know it's going to end up being a big paycheck for me when I get called to fix it.
Personally, I don't want normal end users in the database. For an intranet application (especially one which resides on a Domain) I would provide a single account for application access to the database which only has those rights which are needed for the application to function.
Access to the application would then be controlled via the user's domain account (turn off anonymous access in IIS, etc.).
IF a user needs, and can justify, direct access to the database, then their domain account would be given access to the database, and they can log into the DBMS using the appropriate tools.
I've been responsible for developing several internal web applications over the past year.
Our solution was using Windows Authentication (Active Directory or LDAP).
Our purpose was merely to allow a simple login using an existing company ID/password. We also wanted to make sure that the existing department would still be responsible for verifying and managing access permissions.
While I can't answer the argument concerning Nhibernate or LINQ, unless you have a specific killer feature these things can implement, Active Directory or LDAP are simple enough to implement and maintain that it's worth trying.
I agree with Stephen Wrighton. Domain security is the way to go. If you would like to use mashups and what-not, you can expose parts of the database via a machine-readable RESTful interface. SubSonic has one built in.
Stephen - Keeping normal end users out of the database is nice but I am wondering if in this day and age with so many experienced computer users coming out of University / College if this the right path. If someone wants to automate part of their job which includes a VBA update to a database which I allow them to do via the normal application are we losing gains by restricting their access in this way.
I guess the other path implied here is you could open up the Application via services and then secure those services via groups and still keep the users separated from the database.
Then via delegation you can allow departments to control access to their own accounts via the groups as per Jonathan's post.