So I was using a basic 'if authenticated user' placeholder rule for Firestore when I started using Geofirex. However, when I try to query/use the database with geofirex, my security blocked it. I'm currently running without any rules for the sake of development, so I know everything works, but I have no idea how to add rules to allow this library or have the library identified with the user. Is there even a way to do this?
If a library runs in the same process as the rest of your application code, there is no way to set up separate security for that library. All requests coming from the application are (and should be) treated equally, as there's nothing that inherently makes the library code more trusted than the code of your own application, or the code that malicious user may write.
What you can do is creating an additional collection that only contains the location of each object and its key. You could then point Geofirex to that collection and allow read-access to this data to all users, while securing access to the more sensitive other data about each object. This is what the original GeoFire libraries from Firebase did, and while it leads to more code (to read the additional data objects), it makes it much simpler to secure data access.
Related
I am building flutter mobile app that is intensively using firebase services and firestore.
in app start, the app communicates with firestore to retrieve some basic keys and paramaters that app uses in different services, like APIs Keys, IDs, .. etc.
would like to understand if this approach is secure enough? or there is a possibility that communication (firestore query) to be hacked somehow and the keys are stolen?
Note: I am using simple firebase rule that allow read and write if user is signed in using Firebase Authentication
I can indeed hardcode these keys in the app code, however I prefered this database approach to give myself the chance to change these keys if it is changed by the services providers for any reason.
any answers or links are much apprecaited.
You should assume that any value used inside your client-side application can be found by a malicious user and used for their own purposes.
Once someone has those keys, they can call the APIs that require them differently than what your own application code does, unless you use some other means to prevent this such as Firebase's security rules and App Check.
When using security rules, the best way to prevent somebody from doing something different from your application's use-cases is to encode those use-cases in the security rules too. So instead of just requiring someone to be signed in, expand your rules to validate that only the operations that your own code requires are allowed. Use-case by use-case lock it down, until your cod and rules cover the same set of use-cases.
Also see:
Is it safe to expose Firebase apiKey to the public?
google FireStore security hack from web console
I am trying to shift towards serverless architecture when it comes to building REST API. I came from Ruby on Rails background.
I have successfully understood and adapted services such as Api Gateway, Cognito, RDS and Lambda functions, however I am struggling with putting it all together in optimal way.
My case is the following. I have a simple user based platform when there are multiple resources related to application members say blog application.
I have used Cognito for the sake of authentication and Aurora as the database service for keeping thing like articles and likes..
Since the database and Cognito user pool are decoupled, it is hard for me to do things like:
Fetching users that liked particular article
Fetching users comments
It seems problematic for me because I need to pass some unique Cognito user identifier (retrieved during authorization phase in API gateway) to lambda function which will then save the database record with an external reference to this user. On the other hand, If I were to fetch particular users, firstly I must fetch their identifiers from my relation database and then request users details from Cognito user pool..I lack some standard ways of accessing current user in my lambda functions as well as mechanisms for easily associating databse record with that user..
I have not found some convincing recommended patterns for designing such applications even though it seems like a very common problem and I am having hard time struggling if my approach is correct..
I would appreciate some comments on what are some patterns to consider when designing simple user based platform and what are the pitfalls of my solution. Any articles and examples will also be very helpfull.
Thanks in advance.
These sound like standard problems associated with distributed, indpependent, databases. You can no longer delegate all relationships to the database and get a result aggregating them in some way. You have to do the work yourself by calling one database, then the other.
For a case like this:
Fetching users that liked particular article
You would look up the "likes" database to determine user IDs of those who liked it, then look up the "users" database to determine user details such as name and avatar.
Most patterns follow standard database advice, e.g. in the above example, you could follow the performance-oriented pattern of de-normalising - store user data such as name and avatar against each "like", as long as you feel the extra storage and burden of keeping it consistent is justified by the reduction in queries (probably too many Likes to justify this).
Another important practice is using bulk queries to avoid N+1 queries. This is what Rails does with the includes syntax, but you may have to do it yourself here. In my example, it should only take two queries because the second query should get all required user data in one go, by querying for users matching the list of user IDs.
Finally, I'd suggest you try to abstract things. This kind of code gets messy fast, so be sure to build a well-encapsulated data layer that isolates application code from dealing with the mess of multiple databases.
I am working on an application where I need to setup identity server 4. I have an api as resource. and a web forms application as client.I have few roles like teachers, students, parents in my database. How can I use this custom database and perform authentication and authorization without using identity?
Please suggest.
From your other question here I get a better idea of what you want.
I think one solution for what you want would be to setup identityserver4 in a seperate project with its own seperate database. I noticed the tag identityserver3, but I think it is quite safe to go for identityserver4. It shouldn't make a difference for the client/user since they are conceptually compatible.
1) Give your application a client/secret (which you configure in identityserver) in order to identify your application and grant access to the resource api. Here is some information: http://docs.identityserver.io/en/dev/quickstarts/1_client_credentials.html
You'll only need to configure one client to protect your resource from the outside. The only way to access the resource api is through your application, since your application is making the actual calls. This is also the drawback, you cannot expose the token to the outside world.
Since your client isn't the actual user, you'll need to identify the user. You can use any mechanism based on your current model as you like. A simple user/pass (with or without asp.net identity) could be enough to determine the roles. But please keep in mind that your application has full access to the resource api.
2) However, since identityserver is available, why not use it? Why don't you want to use the identitymodel? I think you should consider to seperate the identity information and your datamodel. Your datamodel shouldn't be aware of the security. And the security has nothing to do with your datamodel.
When you create a seperate database for identityserver you have one place to configure the identity users. All you need is a reference (sub) to the user in the datamodel. http://docs.identityserver.io/en/dev/quickstarts/2_resource_owner_passwords.html
Add claims or roles and everything is in place and you'll see there is no need to keep identity data in your custom database. The structure of your custom database stays intact, including the user table but without the identity data.
I think this is a safer solution and considering the good documentation and sample projects it may even turn out to be a quicker solution.
For example I have 2 databases. One of them is called ecommerce which contains real customer information. Another is called ec1 which basically contains only views from tables of ecommerce.
We use our ec1 database to connect to our website or apps. How secure is this method in terms of back end security?
Only exposing ec1 is better than exposing ecommerce because you can reset ec1 using your "safe" values in case of corruption and you can keep some secret data only stored in ecommerce if it doesn't need to be used by your website or your app.
However, this is only a small portion of backend security. Having two different databases with real data and data views doesn't matter a lot if someone can access your server OR can corrupt your data.
I mean, if someone found a way to get some data he should be not authorized to read, it is bad even if it comes from ec1 and not from ecommerce
So yeah, exposing only views is a BETTER solution, but nothing can be said on the overall security because it mainly doesn't depend on that
EDIT: A detailed explaination of backend security is way beyond the possibility of a simple stackoverflow answer (and probably i am not the best teacher) but for basic server security you must take care of:
- Firewall to stop every request but your webapps ones.
- Updated software
- good database passwords
- The user you use for your application queries must only be able to perform operations on ecl1 database, while the views should be generated with a cron and using a different user
These are the main security enhancement tips that comes to my mind
A little backstory
I have to develop a web application for college. This web application has to do with managing different locations using google maps like pinning new locations adding custom descriptions and so on. The login part is done using facebook (login with facebook). The more interesting part would be that the queries (client-server) would have to be done by using REST.
The part that i try to understand
If i use a database to store my user's unique ID, their online status (online/offline) and somehow (didn't settle actually on the idea) to keep a JSON on the server that would contain each user's pinned locations, would all this actually be ok with the REST paradigm ?
I find mixed answers on the internet and i don't know how to think of the statelessness of the application correctly. A session would not be created but the credentials from the database would be necessary for the users to communicate with each other.
The other side of the question
Considering that i'm mistaken and i shouldn't use the database to store the credentials and locations like that, how am i supposed to keep all that data ? I'm thinking something like JSON cached client-side but what if my client changes the computer, wouldn't this mean that he loses all his data? (Also wouldn't this make MVC handicapped by not having a model?) How do i really keep track of all things.
You're making this way too hard on yourself, try to keep it simple since you probably have a deadline. REST is a way of using APIs with HTTP verbs like GET, POST, PUT, and DELETE. It says nothing about how to store the data behind your APIs.
As for storing the data, a database should be fine. Storing it as JSON in the db could work, but in the end you'll have to parse the json every time that you want to use it, so I would suggest that you store it in a DB in such a way that it can be read easily.
For a beginner (especially if you're doing this for a school project), I would definitely suggest that you set up a relational database like Microsoft SQL Database (Microsoft Stack), or a MySQL/PosGres Database (I think this is what they'd use in linux), but if you wanna skip the relational db approach (because it might not be all that "easy" to get going), you can always try a NoSQL database like MongoDB.
Relevant links to help:
http://rest.elkstein.org/ (REST explained)
http://www.restapitutorial.com/lessons/httpmethods.html (REST verbs)
http://en.wikipedia.org/wiki/Relational_database (what is a relational db)
http://en.wikipedia.org/wiki/Database_normalization (Kinda the goal of relational db.. but note you can go too far...http://lemire.me/blog/archives/2010/12/02/over-normalization-is-bad-for-you/)
http://www.mongodb.com/nosql-explained (NoSQL explanation)