-1

Anybody who knows how to write scripts in Tampermonkey extension or how to create create extension can easily inject javascript code in webpage and access config keys. So how do you secure it?

var config = {
    apiKey: "apiKey",
    authDomain: "projectId.firebaseapp.com",
    databaseURL: "https://databaseName.firebaseio.com",
    storageBucket: "bucket.appspot.com"
};
firebase.initializeApp(config);

Right now only thing I can think of is wrap in anonymous function to avoid variable accessibility globally. which can prevent accessing variable.

It is still not secure, developer can ajax javascript file and parse data using regex, so how do you prevent it?

Another thing I thought of that is using nodejs as backend and use restapi to get data but it also exclude it being real time database. In addition I'd have to use socket.io to transfer data to client side in realtime if firebase update database in realtime in backend.

Because If anyone can inject script to access config keys can also read & write anywhere in database at his own will where read and write permission is granted. which is a security concern. Any keys available on client is risky. so how do you prevent such attack?

Faizan Anwer Ali Rupani
  • 605
  • 11
  • 31

1 Answers1

0

This is a fairly common question. The answer is: no, a client cant write and read from everywhere in the database but only where your rules allow it.

This is exactly like REST, if you have a REST API then all your endpoints are public. What prevents mischief use are the server rules.

In this case, the database rules are in charge of securing and validating the data.

The simplest rule is user is logged in:

Items: {
    .read: if auth != null, 
   .write: if auth != null
}

You can also have more common rules, like owner permissions

user_items: {
   $uid: {
         .read: if auth.uid == $uid, 
        .write: if auth.uid == $uid  
   }
}

The previous example considers a data structure where each user has its own node, but if for any reason you meant to keep it all in the same node it can be done using query rules. My recommendation would be to use the above structure, that way in the future, an admin feature can be added by denormalizing data.

The difference here is you are exposing your credentials if you take a look at them, there is nothing really private but only needed data for Firebase to match the request with your project, beyond that your project has to define the security. Please, take care of securing RTD, Firestore and Storage.

cutiko
  • 9,887
  • 3
  • 45
  • 59
  • That's the thing you're only defining which reference you can read and write. If you give it read permission then the person who is injecting code can also read every entry, no? – Faizan Anwer Ali Rupani May 09 '19 at 14:33
  • Also if you're spam user and created an account for purpose to access database then no point of user authentication – Faizan Anwer Ali Rupani May 09 '19 at 14:35
  • once you give read permission then any user who you gave read permission can read any entry or all entry, similarly if you give write permission then he can update in any entry – Faizan Anwer Ali Rupani May 09 '19 at 14:37
  • give me any website link which uses config keys in client javascript file I'll hack database entries which have read access – Faizan Anwer Ali Rupani May 09 '19 at 14:43
  • 1
    Updated answer. I recommend you to read the docs about rules https://firebase.google.com/docs/database but especially about data structure which seems to be the original miss conception https://firebase.google.com/docs/database this is not a SQL (tables) database, all "animals" can be or can not be in the same place, and can even be in more than one place if needed – cutiko May 09 '19 at 14:45
  • @FaizanRupani: as cutiko explained you can secure access to Firebase/Firestore with its server-side security rules. In there you can validate the data that can be written, and you can control access once you require your users to sign in. If it helps, you can think of the user's UID as their own private API key, which you security rules can check. – Frank van Puffelen May 09 '19 at 14:52
  • your link absolutely tell nothing about firebase security. I know it is not same as sql dababase. you're missing a point. I'm saying anyone can inject JavaScript and access database because It'll be on same domain and any hacker can create fake user to avoid user authentication problem and query all records where read permission is granted – Faizan Anwer Ali Rupani May 09 '19 at 14:53
  • @FrankvanPuffelen again same answer. I'm telling you I can create fake account to bypass user validation and can access all entries of reference where read permission is accessible – Faizan Anwer Ali Rupani May 09 '19 at 14:54
  • In Cutiko's second example, each user can only read and write items that are stored under their UID. Since only they can write those values, and only they can read them, this is essentially their own complete private database. I recommend also reading a few of these results, which walk through how other developers have secured their Firebase database: https://www.google.com/search?q=how+to+protect+the+firebase+against+external+hackers – Frank van Puffelen May 09 '19 at 15:02
  • @FaizanRupani Did you downvote cutiko's answer? If so: can you explain why? Both Cutiko and myself are trying to help you understand how to secure access to your database, which is what you asked. – Frank van Puffelen May 09 '19 at 15:07
  • 1
    If you are truly sure about this then you should do some ethical hacking, create a POC of what you are saying and send it to Firebase, I have contacted support and they are very responsive @FaizanRupani – cutiko May 09 '19 at 15:27
  • 1
    Just to add my 2 cents @FaizanRupani... Injecting a script, may it be using a 3rd party system on a user's browser or using a compromised router would be make it "unsecured". What i get with your concern is that the injected compromised code running on the same domain can now do damage in the database as the user that is currently logged in. – TJ Monserrat May 10 '19 at 00:11
  • 2
    What i think we are forgetting here is that an injected compromised code can also so damage to a secured api point because a request coming from a compromised code will also have the same cookies or jwt to authenticate themselves (remember that a hacker can investigate and eventually access those jwt in memory or just use the session cookie being sent automatically on a request). So again it will not be any different if you do it on a secured api. – TJ Monserrat May 10 '19 at 00:11
  • 1
    Given that, the problem now lies outside on Firebase and on how you secure your website or even your browser. Injecting code on your website enroute (like man in the middle attacks or compromised routers) is very hard if you are using https... And hosting on firebase is by default sends your website on https. If you are hosting it on your own servers, then it is gonna be your responsibility to add https. – TJ Monserrat May 10 '19 at 00:12
  • 1
    Aside from that, 3rd party injection of code on website via browser is the responsibility of user... If the user has installed a compromised extension, then even a very secured website can and will be compromised. The only way to secure all of the data is to make sure you only give the least priveledge security permissions to a given user on a given firebase path. Hope this helps – TJ Monserrat May 10 '19 at 00:12
  • So the only security they have is security rules. That's it huh? – Faizan Anwer Ali Rupani May 11 '19 at 05:59
  • Nope, you can also limit the use of the api key to specific domains. You can also use firebase functions as api and limit the use read/write of firebase to only when using firebase-admin sdk (which frankly limits also the realtime-ness of your app). – TJ Monserrat May 11 '19 at 23:05
  • Right now, i don't really know what's the point of "security rules is just the only security". There's a lot of security practices that are outside firebase but should have been part of the practices when building a website. As said, the api key is just the address.. Much like when accessing google maps api - it is up to you on how you can limit the use via domain name or if you want to prevent accessing of data by any logged in user, you limit via security rules (much like iam roles but on firebase paths) – TJ Monserrat May 11 '19 at 23:10