Thousands of Mobile Apps Leak Data from Firebase Databases | Hacker News Reader

Thousands of Mobile Apps Leak Data from Firebase Databases

securityweek.com

33 pointsauslander14 comments

>The security issue, which the security firm refers to as the Firebase vulnerability

IMO, calling the vulnerability the "Firebase vulnerability" makes it seem like it's a problem on Firebase's side. But is it really their problem? At what point do we start blaming the developers instead of the service?

If the following quote from the article is true, it seems like Firebase is not making security easy for developers: "One of the most popular backend database technologies for mobile apps, Firebase does not secure user data by default. It does not warn developers when data is not secure and does not provide third-party encryption tools either. To ensure data is secure, app builders need to specifically implement user authentication on all database tables and rows, but that rarely happens,"

Google shouts at you, about 500 times, to secure your Firebase instance. Tutorials are thrown at developers left and right, and the docs mention it again and again.

And the security system is super simple to implement. If the built in language is too hard, a simplified templating language is also provided.

The plaintext password thing just confuses me. One of Firebase's big draws is integration with their auth system. Why in the world is anyone storing passwords in Firebase? Unencrypted?

How many times do we need to go through issues like this before people realize that just yelling louder has no effect? Services like this should simply not function at all until basic things like a password are put in place.

> Services like this should simply not function at all until basic things like a password are put in place.

New Firebase instances starts off locked down by default, not allowing global reads or writes.

The fact that this was not the default since the inception of the service is inexcusable. Sadly, too many other projects still take the approach of yelling at people in some document somewhere instead of forcing security by default.

I’m guessing because most developers have no training in web security. Using Firebase as an authentication tool, you’re not supposed to have access to users passwords — unless you are specifically parsing for it and storing them into the database after account creation.

Firebase used to be open by default, (to ease the dev experience, presumably), but sometime around the Google acquisition became private-by-default. It also warns you incessantly when your security rules are too open.

I suspect (hope?) most of the apps still using it insecurely came from before the acquisition by Google.

It seems obvious to most people on HN that you'd have to secure user data to only be accessible by that user but I've found many young mobile devs to not grasp these 'backend' basics which is unfortunate.

In a way I blame this on Apple/Google for making their platforms convoluted enough that people have to spend years learning how to develop Android and iOS but not have a proper understanding of the web services powering APIs.

Thought about this some more and it's definitely not just Google/Apple's fault per se but the respective mobile communities strongly push technology churn a la JS frameworks. Except in Androids case it's, getting your architecture right, using MVP, dissecting Dagger and dependency injection, learning kotlin, learning rxjava, learning MVI because mvp isn't good enough anymore.

Eventually you just get caught up in this constant flurry of learning more without actually learning anything

It’s due to laziness. Most of the times when I looked up how to implement a feature via Firebase — such as public profiles — there were instructions on implementation and on what new rules to add.

It’s either that or the developer simply doesn’t understand the abstraction of Firebase. You can easily check if the rules work by loading up your browser console and trying to access different branches of data with varying credentials.

It’s not a vulnerability in Firebase, setting aside the question of whether it’s a Firebase “problem” (ie how the blame is divided).

How is it true that apps using Firebase “rarely” secure it properly, if only 10% of apps using Firebase are vulnerable?

A lot of mobile apps are very poorly written.

Yes, this is a problem on Firebase side.

If your software can be configured in an insecure manner, that's what people will do.

There are so many developers out there that every possible mistake will be made. The easier the mistake is to make, the more common it will be. If the mistake requires the developer to perform an action to avoid it, it will be ubiquitous.

In 2018, security can no longer be an afterthought. Your product must be secure out of the box. Insecure configurations must be hard or impossible to set up.

You can't offer an insecure "development mode", because that is what people will use in production.

(PS: Of course it is also the developers fault. But that is no excuse for the vendor. There are lots of incompetent developers out there. Confused developers are not an exception. Your product must be secure even if people don't read the documentation)

This reminds me of the old MongoDB 'issue' where MongoDB was accused of being insecure because developers failed to secure their database instances properly.

Aside from that, Firebase has learned from their pre-aquisition time and now sets all new DB instances to locked.

Reply on news.ycombinator.com