I’m certainly no web security expert, but shouldn’t Tea’s junior network/backend/security developers, let alone seniors, know how to secure said Firebase or S3 buckets with STARTTLS or SSL certificates? Shouldn’t a company like this have some sort of compliance department?
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 that can be extracted or sniffed.
Obviously there are ways around this too, but it’s not just “use TLS”.
Encrypting the transmission doesn’t do much if every app installation contains access credentials that can be extracted or sniffed.
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 encrypts the data on 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 a DNN researcher. Thus, 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.
Edit: I don’t know why I’m down-voted. My questions were sincere.
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. https://www.cisecurity.org/
Brother, I need the “remedial” lessons since I self-host a lot of my experimental DNN solutions on a GPU cluster served via CasaOS/Ubuntu-Server LTS.
I’ve followed basic tutorials about nginx, end-to-end encryption, and DNS, but I need more knowledge and training about the theory behind modern security best practices. I think I’m doing okay but I have this ever-present anxiety that I’ve overlooked something and my ass (i.e., sensitive data) is really just hanging out in the wind.
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
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.
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.
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.
I’m certainly no web security expert, but shouldn’t Tea’s junior network/backend/security developers, let alone seniors, know how to secure said Firebase or S3 buckets with STARTTLS or SSL certificates? Shouldn’t a company like this have some sort of compliance department?
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 that can be extracted or sniffed.
Obviously there are ways around this too, but it’s not just “use TLS”.
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 encrypts the data on 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 a DNN researcher. Thus, 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.
Edit: I don’t know why I’m down-voted. My questions were sincere.
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. https://www.cisecurity.org/
Brother, I need the “remedial” lessons since I self-host a lot of my experimental DNN solutions on a GPU cluster served via CasaOS/Ubuntu-Server LTS.
I’ve followed basic tutorials about nginx, end-to-end encryption, and DNS, but I need more knowledge and training about the theory behind modern security best practices. I think I’m doing okay but I have this ever-present anxiety that I’ve overlooked something and my ass (i.e., sensitive data) is really just hanging out in the wind.
Thank you for your recommendation.
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
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.
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.
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.
I am not sure, but I read somewhere that the developer(s) used vibe coding to create the app so…
A lot of people have speculated that.
According to their statement their code was written in Feb/2024 and predates “vibe coding”