Comment on Women’s ‘red flag’ app Tea is a privacy nightmare
pivot_root@lemmy.world 3 days ago
Tea was storing its users’ sensitive information on Firebase, a Google-owned backend cloud storage and computing service.
Every time. With startups, it’s always an unsecured Firebase or S3 bucket.
My hey we’re probably using Firestore as their database without authenticating their api calls to firebase functions. Basically leaving their api endpoints open to the public Internet.
They could have connected service account and used some kind of auth handshake between that and generate a temporary login token based on user credentials and the service account oauth credentials to access the api. but they probably just had everything set to unauthenticated
Yup. It sounds like they were following security worst practices.
I get doing that in Dev for testing before launch, but in production? that’s insane.
Like it has to either be a junior developer playing the role of lead or some serious lack of web dev fundamentals haha
I’d argue that it should not even be done in Dev. Dev, staging/testing, and prod environments should all be as close to one another as possible, especially for infra like datastores.
It’s a little more complex than that. If you want the app on the user device to be able to dump data directly into your online database, you have to give it access in some way. Encrypting the transmission doesn’t do much if every app installation contains access credentials.
Obviously there are ways around this too, but it’s not just “use TLS”.
NeilBru@lemmy.world 2 days ago
I’m certainly no web security expert, but shouldn’t a basic developer know how to secure said firebase or S3 buckets with STARTTLS or SSL certificates?
zqps@sh.itjust.works 2 days ago
It’s a little more complex than that. If you want the app on the user device to be able to dump data directly into your online database, you have to give it access in some way. Encrypting the transmission doesn’t do much if every app installation contains access credentials.
Obviously there are ways around this too, but it’s not just “use TLS”.
NeilBru@lemmy.world 2 days ago
Encrypt the credentials then? Or OAUTH pipeline, perhaps? Automated temporary private key generation for each upload (that sounds unrealistic, to be fair)? Can credentialing be used for intermediary storage that’s encrypted at that server and then decrypted on the database host?
Clearly my utter “noobishness” is showing, but at least it’s triggering a slight urge to casually peruse modern WebSec production workflows. I am but a humble DNNs-for-parametric-CAD-modelling (lots of Linear Algebra, PyTorch, and Grasshopper for Rhino) researcher. I am far removed from customer-facing production environments, and it shows.
Any recommendations on literature or articles on how engineers solve these problems in a “best practices” way that you can recommend? I suppose I could just look it up, but I thought I’d ask.
nickwitha_k@lemmy.sdf.org 2 days ago
You’ve got the right ideas. Noone should ever be storing any password in plaintext. It should always be hashed and the hash stores. That’s like WEBDEV99 (remedial course, not even 101).
Really. Despite your stated “noobishness”, you basically landed in the territory of best practices right of the bat.
If you’re looking for a good source of best practices, the CIS benchmarks are great. www.cisecurity.org
Chulk@lemmy.ml 2 days ago
Wouldn’t some sort of proxy in between the bucket and the client app solve this problem? I feel like you could even set up an endpoint on your backend that manages the upload. In other words, why is it necessary for the client app to connect directly with the bucket?
Maybe I’m not understanding the gist of the problem
zqps@sh.itjust.works 1 day ago
Exactly, it’s not necessary. It’s bad / lazy design. You don’t expose the DB storage directly, you expose a frontend that handles all the authentication and validation stuff before accessing the DB on the backend. That’s normal Client-Server-Database architecture.
nickwitha_k@lemmy.sdf.org 2 days ago
Yeah. You also landed on a correct thought process for security. Cloud providers will let you make datastores public but that’s like handing over a revolver with an unknown number of live chambers and saying “Have fun playing Russian roulette! I hope you win.” Making any datastore public facing, without an API abstraction to control authN and authZ is not just a bad practice, it’s a stupid practice.
gian@lemmy.grys.it 2 days ago
I am not sure, but I read somewhere that the developer(s) used vibe coding to create the app so…
Canconda@lemmy.ca 2 days ago
A lot of people have speculated that.
According to their statement their code was written in Feb/2024 and predates “vibe coding”
gian@lemmy.grys.it 1 day ago
What intrigue me is this:
So they used vibe coding, they are only saying that they think/hope that it is not the cause of the break (and maybe also of the second one)
And if vvibe coding is not caused then they are even more incompetent.
GissaMittJobb@lemmy.ml 2 days ago
SSL is not the tool you need in this case, although you should obviously already be running exclusively on encrypted traffic.
The problem here is one of access rights - you should not make files default-available for anyone that can figure out the file name to the particular file in the bucket. At the very least, you need to be using signed URLs with a reasonably short expiration, and default all other access to be blocked.
NeilBru@lemmy.world 2 days ago
As I mentioned in other comments, I am a noob when it comes to web-sec best practices, so please forgive what may be dumb questions.
Is it really just permission rights “over-exposure” issue? Or does one need to also encrypt and then decrypt the data itself that must be sent to a database?
Also, if you have time, recommend any links to web/cloud/SaaS security best practices “for dummies”?
nickwitha_k@lemmy.sdf.org 1 day ago
There’s nothing to forgive. Asking questions and being curious is how you learn this stuff.
From what I’ve read, it’s more fundamental than that. It’s a basic architecture issue. The datastore was publicly accessible, which it should never be. If they had it setup according to best practices, with an API to proxy access and auth, the datastore’s permissions would be of minimal consequence, unless their network was compromised (still best practice to secure it and approach with a zero-trust mindset).
Generally, cloud datastores handle encryption/decryption transparently, as long as the account accessing data has authorization to use the key. They probably also didn’t have encryption setup.
Here are some more resources: