
Thousands of Apps Leak Sensitive Data via Misconfigured Firebase Back Ends - kjhughes
https://www.bleepingcomputer.com/news/security/thousands-of-apps-leak-sensitive-data-via-misconfigured-firebase-backends/
======
wnsire
This is why I hate giving my personal info when "Signin Up" for online
services of stuff made by startups. They usually know nothing about Back End
security , and today's trend is to create product that "sale" and to ship as
fast as possible regardless of compliance or security.

One way or another it usually end up being stored in a completely unsecured
manner.

This is even more outrageous knowing how secure Firebase actually is. The
documentation even contains a "Securing your Data Model" section .

~~~
cremp
I don't think it is about compliance or security at all; just developers that
aren't competent.

> 2.6 million plaintext passwords

Anyone who is actually competent knows hashing at a minimum; and it costs
nothing to implement, both time and money wise.

All of this, because Johnny over here read a tutorial on how to make your own
app.

The downside of development is that, you do get these people who 'stain' the
title, because they just read it and followed blindly instead of actually
learning.

~~~
jmtulloss
This is especially surprising because Firebase provides authentication APIs
that do the right thing by default. This means devs are doing more work to get
to a less secure solution.

~~~
cremp
Or treating it like any other database; and just using it because its
'popular.' Those 'developers' who do that (use popular just because,) are just
the people who stain the title.

------
z5h
There is a permission testing tool built in to firebase. And excellent
documentation.

This is 100% the fault of developers.

~~~
azinman2
Perhaps knowing that humans are fallable and that many of these app devs are
educated solely in a 2 month boot camp, Firebase might do something to make
this less likely.

~~~
master-litty
Immediate suggestions that come to mind?

~~~
azinman2
Not allowing unauthenticated requests? Look for things like plaintext
passwords from one of many giant dictionaries of commonly used passwords and
flag that behavior? Look for fields that match credit card numbers? Do better
in documentation, especially around any schema creator?

I don’t know enough about the exact security problem (I don’t use firebase)
but I’m guessing tossing your hands in the air isn’t the only option.

------
yohann305
The underlying issue here is that Firebase was sold as the answer to the not-
so-techy people that wanted to create apps but couldn't necessarily handle the
backend and here the issue is that Firebase should have thought that the
majority of the audience thought Firebase would handle backend security for
them as well.

Yes, Firebase team messed up here, but technically speaking it's not too late
to fix if done right now. I noticed Firebase already added big banners in
Firebase dashboard to make people aware of this issue, or maybe it's a way for
Firebase team to cover their asses by saying ___we told you so!!_ __It 's a
good step towards fixing this issue but it's still not enough.

~~~
filleduchaos
What on earth? Firebase has had the notice that your database is open to
public access (if set that way) for ages. They've had IAM rules for years.

------
vlucas
> 2.6 million plaintext passwords and user IDs

This seems really odd to me. If you use Firebase Auth, you never see or get
the users's password at all unless you are also copying it (on user login or
registration) and storing it in another collection on your own, and then not
hashing or securing that. The 2.6 million number could also conceivably be
just a handful of really popular apps (or even just one!).

------
patwolf
I always figured there were a lot of poorly-secured Firebase apps out there.

My experience with Firebase Database is that it's great for apps with
extremely simple models, or for PoCs where security and performance aren't a
concern.

If each user's data is independent and isolated, then it's not a problem. But
for more complex cases, e.g. two particular users can see a piece of data
because they belong to the same group, the complexity of trying to properly
secure the database isn't worth whatever efficiencies you would gain over
using a more traditional database.

However, if your goal is to create an offline-capable app, then there aren't
necessarily going to be any simple alternatives. CouchDB is good for offline
but doesn't necessarily solve security.

------
monksy
This is what happens when:

1\. You let inexperienced devs make big decisions. 2\. "MVP" and ignore all of
the other parts of the dev lifecycle.

~~~
meritt
3\. Everything critical to your company is a 3rd party SaaS accessible via
public IPs.

#1 and #2 have been symptomatic of the tech industry since at least the 90s.
The difference back then was the surface area was generally limited to your
private network only.

------
kjhughes
A developer-level explanation would be helpful here.

Was the mistake in the default Firebase configuration settings, or were common
poor choices made by each of the app developers independently?

~~~
ProblemFactory
Firebase Database default settings make the entire database world-readable and
world-writable by all "authenticated users". But once you have enabled
authentication, then that means anyone who signs into your app with a Google
account. Restricting users to only access their own data requires
understanding and writing "security rules".

It's the most irresponsible default I have seen in practice.

~~~
z5h
I disagree. I bet if the default was no access, developers would simply enable
all access (and not even realize they could restrict access to authenticated
users). So the default is likely much safer than what would otherwise happen.

Let's not forget that there is a security/permissions testing feature built
right into Firebase. It would literally take 1 minute for a dev to ask and
test: hey, can people read each other's data?

~~~
rhizome
_developers would simply enable all access (and not even realize they could
restrict access to authenticated users). So the default is likely much safer
than what would otherwise happen._

That's not what "safer" means. You cannot say that that's what would happen,
either.

------
pnwguy
Could this be related to Typeform data breach?

[https://news.ycombinator.com/item?id=17425453](https://news.ycombinator.com/item?id=17425453)

------
swrobel
"The leaked information weighed more than 113 GBs"

Love this turn of phrase

