Live data from Hacker News

I pwned half of America's fast food chains simultaneously

mrbruh.com

101–110 of 513 posts

Re: I pwned half of America's fast food chains simultaneously

#101

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 feel this needs a framework (not a library) to take care of it all. Abstract away the webbyness. Something like Elm, with a type that represents data, and behind the scenes it does all the ServiceWorker and syncing crap for you.

Re: I pwned half of America's fast food chains simultaneously

#102

Firebase 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.

Re: I pwned half of America's fast food chains simultaneously

#103

This 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.

Of course, but it that’s good in most cases as then you don’t get an overreaction.

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

#104
post #30

Earlier 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.

> 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

#105
post #21

This 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.

I don’t disagree with this either, I just didn’t think of it when I put my response in.

Naming and shaming does work.

Re: I pwned half of America's fast food chains simultaneously

#106

Firebase 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.

It's worth noting that Firebase doesn't have a true offline-first architecture, but rather cloud-first: By default, queries run against the cloud and results of those specific queries are temporarily cached on the client. By default Firestore will try to reach the server first before falling back to the local cache, which can result in a subpar UX on a patch network connection. It does also provide store-and-forward of updates from client to server. But it's not a true offline-first architecture since it does not preemptively sync a database to the local user device for offline-by-default access.

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

#108

Firebase 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.

I'm coming to this conclusion as well.

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

#109

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.

https://electric-sql.com/

https://www.powersync.com

https://watermelondb.dev

https://replicache.dev

Re: I pwned half of America's fast food chains simultaneously

#110
> Timeline (DD/MM)

> 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.

Post reply on HN