Earlier quoted context omitted.
Firebase's whole premise is seamless syncing between locally cached data and your backend. If you "just use Postgres", life is simpler until your user goes offline/runs out of mobile data/whatever, and then they're immediately screwed.
This is the exact use-case I want to optimize for. Offline-first with robust and seamless syncing. Firebase keeps promising it but I would love to find more transparent tools that work better on mobile + web.
I pwned half of America's fast food chains simultaneously
101–110 of 513 posts
Re: I pwned half of America's fast food chains simultaneously
#102Firebase is a shitshow. I say this as someone who really tried to like it and sadly built a project for a client using it. Other than this security vuln, the issues vs. just using postgres are: * It is more work! Despite being a backend as a service it is much less code to just write a simple API backend for your thing both in time to do it and time to learn how to do it. Think of Firebase as being on the abstraction…
Re: I pwned half of America's fast food chains simultaneously
#103This isn’t owning fast food chains; rather compromising some AI startup that has some of them as a customer. Title is misleading.
TBF your proposed title is less snappy.
The right people will read it (Chattr.ai’s customers) and respond . Right now everyone looks at it and some CISO will overreact and make everyone go check their Firebase configurations which may likely be a non-value add.
Re: I pwned half of America's fast food chains simultaneously
#104Earlier quoted context omitted.
No, the default is no access to anything. You have to write rules that allow access to each record in the database. It sounds like the rule that they wrote only checked that the request _is logged in_, because they assumed that visitors can't create their own accounts.
Which, even if that assumption were true, is still bonkers, because from what I see in the article they had no partitioning between tenants or permissions checks for different user roles. So even if they hadn't accidentally allowed creating new accounts, any account on any one of their existing customers had full access to every row in the database.
Correct. :/
Re: I pwned half of America's fast food chains simultaneously
#105This isn’t owning fast food chains; rather compromising some AI startup that has some of them as a customer. Title is misleading.
I think it’s incomplete. The startup needs to be named and shamed on the title.
Naming and shaming does work.
Re: I pwned half of America's fast food chains simultaneously
#106Firebase is a shitshow. I say this as someone who really tried to like it and sadly built a project for a client using it. Other than this security vuln, the issues vs. just using postgres are: * It is more work! Despite being a backend as a service it is much less code to just write a simple API backend for your thing both in time to do it and time to learn how to do it. Think of Firebase as being on the abstraction…
Firebase's whole premise is seamless syncing between locally cached data and your backend. If you "just use Postgres", life is simpler until your user goes offline/runs out of mobile data/whatever, and then they're immediately screwed.
Regarding Postgres, that is where tools like PowerSync (disclosure: co-founder) and ElectricSQL are useful, which are both sync layers for Postgres for offline-first architecture.
Re: I pwned half of America's fast food chains simultaneously
#107Re: I pwned half of America's fast food chains simultaneously
#108Firebase is a shitshow. I say this as someone who really tried to like it and sadly built a project for a client using it. Other than this security vuln, the issues vs. just using postgres are: * It is more work! Despite being a backend as a service it is much less code to just write a simple API backend for your thing both in time to do it and time to learn how to do it. Think of Firebase as being on the abstraction…
All roads lead back to RDBMS, it's amazing how this piece of theory just works.
Something like DynamoDB can be great for simple data. I liked the idea of Graphql (technically the API query and not the database). Both of them turn into hot garbage once you get into complex data, especially if it's being aggregated from multiple sources. Or maybe the systems I work with just implemented them poorly.
Re: I pwned half of America's fast food chains simultaneously
#109Earlier quoted context omitted.
Firebase's whole premise is seamless syncing between locally cached data and your backend. If you "just use Postgres", life is simpler until your user goes offline/runs out of mobile data/whatever, and then they're immediately screwed.
This is the exact use-case I want to optimize for. Offline-first with robust and seamless syncing. Firebase keeps promising it but I would love to find more transparent tools that work better on mobile + web.
Re: I pwned half of America's fast food chains simultaneously
#110> 06/01 - Vulnerability Discovered
> 09/01 - Write-up completed & Emailed to them
> 10/01 - Vulnerability patched
Note those dates are DAY-MONTH. At least they patched it within a single day.
I find it funny that the author found a massive vulnerability but chose to wait a couple days to report it so they could finish a nice write-up.
Reminds me of my experience with HackerOne: We had some participants who would find a small vulnerability, but then sit on it for months while they tried to find a way to turn it into a larger vulnerability to claim a higher prize.
Then when they finally gave up on further escalation and submitted it, they'd get angry when we informed them that we had already patched it (and therefore would not pay them). The incentives in infosec are weird.