6 ms·
I just want to call out that there is a lot of blame put on firebase here in the comments but I think that's just people parroting stuff they don't actually kno
by zachrip 2y ago
I just want to call out that there is a lot of blame put on firebase here in the comments but I think that's just people parroting stuff they don't actually know about (I don't use firebase, I have tried it out in the past though). This isn't some edge case or hard to solve thing in firebase, this is the easy stuff.
The real issue here is that someone wrote an api that trusted the client to tell it who they were. At the end of the day this is an amateur mistake that likely took a 1 line diff to fix. Don't believe me? Check out the docs: https://firebase.google.com/docs/rules/rules-and-auth#cloud-firestore https://firebase.google.com/docs/rules/rules-and-auth#cloud-... - `request.auth` gives you the user id you need (`request.auth.uid`).
- tr3ntg 2y agoAs someone with an app built on firebase, yes. As the author rightly points out, it's very easy to misconfigure, but basic security practices like these are highlighted in bright, bold warning text in the Firebase docs. Security rules are meant to be taken seriously, and it's your only line of defense.
- bichiliad 2y agoI think a system that makes it this easy to shoot yourself in the foot is probably not a great system. Documentation is important, and I'm glad it's clear and obvious, but humans make mistakes. You'd hope that the mistakes have less dire consequences.
- swatcoder 2y ago> bold warning text in the Firebase docs. Unfortunately, we currently have an industry where highly paid "engineers" unironically believe that their job can be done by reading/watching random tutorials, googling for StackOverflow answers, and pasting code from gists. Attentively reading documentation or developing a mental model of how your tools work so that you know how they are built to be handled does not make it on to any job listing bullet points. It presumably fell off the bottom in favor of team spirit or brand enthusiasm or whatever. How many tutorials, community answers, and gists do you think conveyed that warning?
- 725686 2y agoNah, just ask ChatGPT.
- firewolf34 2y agoChatGPT would have probably parrotted the bold text. It is always super concerned about risks.
- ggregoire 2y agoReading/watching random tutorials and asking basic questions on SO __instead of reading the official docs__ is a trend I've observed for the last 10 years. Even for stuff pretty well documented like Python, Postgres, React, etc.
- prilo 2y agoI often wonder how much this can be attributed to the pretty awful SEO of most documentation. I write mostly Python at work and it's infuriating how often GeeksForGeeks, W3Schools, Programiz, or RealPython pop up when I'm just trying to reference like, the arg order of a builtin, or the particular behavior. Django is worse, I often feel like I can't even find the doc when I know it's there and read it before.
- kevin_thibedeau 2y agoDocumentation is largely static content. It isn't their job to play SEO games to convince search engines to surface it in the query results. Documentation is not a revenue generator for Google so it gets buried below the sites with Doubleclick ads.
- Vegenoid 2y agoAttempting to find the relevant docs page via search engines is generally not a good way to go, you should go to the documentation and search from there. Bookmark the landing page of the documentation.
- 2y ago
- wredue 2y agoNobody reads docs dude. They copy and paste stack overflow answers, and now, copilot answers, which is going to be based on stack overflow ultimately anyway.
- NewJazz 2y agoJust with less context and review.
- BobaFloutist 2y agoMaybe docs should try to be consistently more accurate, up to date, and legible than (even) stack overflow answers ¯ \ _ ( ツ ) _ / ¯
- roywiggins 2y agoNone of that matters if it doesn't show up first or second in Google results.
- deleted 2y ago[deleted]
- Vegenoid 2y agoI have heard this said by many people: “I don’t look at documentation because it usually is inaccurate/out of date” There’s plenty of people sharing anecdata about bad docs, and I’ve dealt with my fair share. But my anecdata is that engineers who habitually go to the docs directly and read them gain a better understanding and write better software than those who do not. I believe that most software for engineers has documentation that is more informative than stack overflow and blog posts.
- wredue 2y agoI support reading docs first for questions, but man some truly are terrible. Like cmake. This just vomits a dissertation at you for each function without really ever saying what it does or how to use it. That’s why there’s so many different sites and GitHub repos with samples. 95% of which are completely out of date (which is a problem cause people looking for these samples probably aren’t on the ups with being able to tell if they’re out of date)
- rakoo 2y ago> it's very easy to misconfigure, but basic security practices like these are highlighted in bright, bold warning text in the Firebase docs. I'm sorry but if the whole design is "one big database shared with everyone and we must manually configure the database for auth" there is a problem that's deeper than just having to read the doc. It means the basic understanding of what it means to keep data as private as possible is not understood. A shared database only works when the server accesses it, not when client has direct access. What Arc needs is to segregate each user's data in a different place, in the design of the database, not as part of configuration of custom code. Make it impossible to list all user's data, or even users. When, not if, an id is guessed, related data becomes accessible by someone else; make it so that someone else still can't read it, or can't replace it.
- esperent 2y agoAlso how does this work legally with regards to data sovereignty? Is it just a case of hoping nobody notices/complains?
- NewJazz 2y agoAt the end of the day this is an amateur mistake God I wish. More than one of my coworkers has made this exact mistake with our (thankfully internal) front-end apps.
- albedoa 2y agoAre you defining amateurs as people who are not your coworkers? It can still be an amateur mistake.
- randomdata 2y agoCoworker implies paid work, and therefore they are not amateurs. They very well may make the same mistakes, but those mistakes would be professional mistakes.
- JohnMakin 2y agoWhy this level of pedantry when the meaning is absolutely clear? A professional can make an amateur mistake. This makes perfect sense. That isn't implying the professional is actually an amateur, but that he made a mistake that an amateur would make.
- ghodith 2y agoFor some added pedantry: aren't all the mistakes that a professional might make, also ones an amateur would make? In fact, it seems like an amateur is likely to run into all mistakes more often, thereby making all mistakes amateur mistakes; unless there some class of mistake that amateurs are better at avoiding?
- digging 2y agoThere are probably mistakes an amateur cannot make because they can't penetrate the problems where the mistakes would be made.
- 2y ago
- kfarr 2y agoAgreed, if I understand correctly the fix to this issue would be the following rules inside of a "match" statement in firestore.rules which is plainly documented as firebase firestore security 101: ``` // Allow create new object if user is authenticated allow create: if request.auth != null; // Allow update or delete document if user is owner of document allow update, delete: if request.auth.uid == resource.data.ownerUID ```
- cutemonster 2y agoIs there no Allow-read? Edit: Yes, allow read, update, delete: if request.auth != null && request.auth.uid == userId;
- GVRV 2y agoDidn't they already have these rules in place? And the vulnerability was when the owner was updating the resource to have a new owner?
- kfarr 2y agoUnclear if they had these rules in place already but I'm curious... If the rule permits writing when the userid matches, presumably there is nothing stopping the write operation to change the userid value, to your point. Which then leads me to the next question, what is the practical way to write rules against that operation?
- GVRV 2y agoIn my limited experience, I've seen it handled by adding the user's ID in the path of any resource that belongs to a particular user, so that the user ID from the resource path can be compared with the authenticated user ID as a security rule condition. But as expected, you can validate the incoming data as well https://firebase.google.com/docs/firestore/security/rules-conditions#data_validation https://firebase.google.com/docs/firestore/security/rules-co... but this would need to be done for any attribute that might lead to a change of ownership.
- bcrosby95 2y agoIt's interesting to see software engineers going from rolling their own auth, to not rolling their own auth, to not even noticing this quite blatant security problem. It doesn't matter if you roll your own auth or not, you need to understand a very basic fundamental of it all: never trust the client.
- vertical91 2y agoThis is what happens when you hire solely based on leetcode skill. A shit-tier engineer can master leetcode within months, but a good engineer will probably struggle at Find Nth Smallest Sum problem because he spends more time reading and thinking about code. Leetcode is a fucking joke to the industry, gone are the days when you actually had good code with devs who spent time thinking about information architecture. In my experience boomer devs are actually the only ones who write idiomatic code. Millennial and Gen-z devs are the worst, they have no understanding beyond basic function calling.
- kerkeslager 2y agoA security plan which depends on any person never making an amateur mistake, is an amateur mistake.
- nsonha 2y agothe whole idea of firebase is flawed as logic that belongs to a server is now on the client side. I don't know much about security but that sounds like making any centralized rule (eg security) hard to implement. It also tends to expose more internal logic than the client needs to know, which is bad in both software design and security.