5 ms·

I think that's throwing the baby out with the bathwater; sane defaults are still an important thing to think about when developing a product. And for something

I think that's throwing the baby out with the bathwater; sane defaults are still an important thing to think about when developing a product. And for something as important as a database, which usually requires authentication or storing personal information, let your tutorials focus on these pain points instead of the promise of a database-driven app with only clientside code. It's awesome, but I think it deserves the notoriety for letting you shoot yourself in the foot and landing on the front page of HN. Author also found a similar exploit via Firebase for the Arc Browser[0] I have a similar qualm with GraphQL. [0] https://kibty.town/blog/arc/ https://kibty.town/blog/arc/

cdmyrm 2y ago
Any purported expert who uses software without considering its security is simply negligent. I'm not sure why people are trying to spin this to avoid placing the blame on the negligent programmer(s).
- misiek08 2y ago
  Weak programmers do this to defend this group making crap software. I agree that defaults should be secure and maybe there should be request limit on admin, full access token - but then people will just create another token with full access and use it.
- Eisenstein 2y ago
  And if it is the programmer's fault, what can we do about it? People are trying to avoid finding a solution that isn't throwing their hands up in the air. We either need to solve the problem in a place that is effective with the situation as it is (the tools) or we need to solve the situation such that it has consequences for doing the wrong thing on the part of the developer. Which shall it be?
  - ImPostingOnHN 2y ago
    Since those are only 2 options, and there are many more options, I'll pick option 3: convince people to value and fund universal education more from preschool on, building a better foundation for engineers and other professions in the decades following. In addition to that, it'd be cool if the blameless postmortems were made public, so everyone could learn from them. As for the other 2 options of restricting freedom, and extremely blameful postmortems, I reject both.
    - Eisenstein 2y ago
      Yes, being held accountable for your decisions is a restriction on your freedom.
      - ImPostingOnHN 2y ago
        I still choose the third option, because it is the better of the three, compared to restricting what functionality the software people write is allowed to have, and extremely blameful postmortems (which are bad).
        Eisenstein 2y ago
        All restrictions are bad, and accountability is bad. Got it. I'm glad to have had this discussion with you; very thought provoking.
        ImPostingOnHN 2y ago
        Again, I still choose the third option, because it is the better of the three, compared to restricting what functionality the software people write is allowed to have, and extremely blameful postmortems (which are bad). You seem really stuck on the first two options. Why does it matter, given that the third is the best? Do you still insist upon a false dichotomy?
        Eisenstein 2y ago
        It isn't exactly surprising that someone who is the beneficiary of a system which has no accountability is against the imposing of such, I was just hoping you had something better to offer back than 'I don't like it' and assertions that something is bad without ever explaining why. I have no idea why 'blameful postmortems' are bad because you never told me, you just say it is. Why should I change my mind in that case?
        ImPostingOnHN 2y ago
999900000999 2y ago
I don't know what exactly happened here, but Firebase has two defaults. Test access rules which auto expire and are insecure, or production rules which require auth. If you do something stupid, like keep ignoring the insecure warning and updating them so they don't expire, that's your fault. In no other industry do workers blame their tools.
- prophesi 2y ago
  The issue usually lies in there not being enough security rules in place, not in keeping insecure rules active. For instance, for the Arc incident which we were given more information on, it was due to not having a security rule in place to prevent unauthorized users from updating the user_id on Arc Boosts in the Firestore. Go into any other industry and hear when they say, "shoot yourself in the foot", and you've likely stumbled upon a situation where they blame their tools for making it too easy to do the wrong thing.
  - 999900000999 2y ago
    If you don't setup any access rules in Firebase, by default it'll deny access. This means someone setup these rules improperly. Even if, you're responsible for the tools you use. We're a bunch of people getting paid 150k+ to type. It's not out of the question to read documentation and at a minimum understand how things work. That said I don't completely disagree with you, if Firebase enables reckless behavior maybe it's not a good tool for production...
    - prophesi 2y ago
      And I don't necessarily disagree either; good callout that it _was_ about improperly configured ACL's, I meant more that it wasn't related to keeping test rules alive. For 150k+ salaries, frontend dev salaries are generally a lot less than their backend counterparts. And scrappy startups might not have cash for competitive salaries or senior engineers. I think these are a few of the reasons why Firebase becomes dangerous.
      - 2y ago

cdmyrm 2y ago

Any purported expert who uses software without considering its security is simply negligent. I'm not sure why people are trying to spin this to avoid placing the blame on the negligent programmer(s).

misiek08 2y ago
Weak programmers do this to defend this group making crap software. I agree that defaults should be secure and maybe there should be request limit on admin, full access token - but then people will just create another token with full access and use it.
Eisenstein 2y ago
And if it is the programmer's fault, what can we do about it? People are trying to avoid finding a solution that isn't throwing their hands up in the air. We either need to solve the problem in a place that is effective with the situation as it is (the tools) or we need to solve the situation such that it has consequences for doing the wrong thing on the part of the developer. Which shall it be?
- ImPostingOnHN 2y ago
  Since those are only 2 options, and there are many more options, I'll pick option 3: convince people to value and fund universal education more from preschool on, building a better foundation for engineers and other professions in the decades following. In addition to that, it'd be cool if the blameless postmortems were made public, so everyone could learn from them. As for the other 2 options of restricting freedom, and extremely blameful postmortems, I reject both.
  - Eisenstein 2y ago
    Yes, being held accountable for your decisions is a restriction on your freedom.
    - ImPostingOnHN 2y ago
      I still choose the third option, because it is the better of the three, compared to restricting what functionality the software people write is allowed to have, and extremely blameful postmortems (which are bad).
      - Eisenstein 2y ago
        All restrictions are bad, and accountability is bad. Got it. I'm glad to have had this discussion with you; very thought provoking.
        ImPostingOnHN 2y ago
        Again, I still choose the third option, because it is the better of the three, compared to restricting what functionality the software people write is allowed to have, and extremely blameful postmortems (which are bad). You seem really stuck on the first two options. Why does it matter, given that the third is the best? Do you still insist upon a false dichotomy?
        Eisenstein 2y ago
        It isn't exactly surprising that someone who is the beneficiary of a system which has no accountability is against the imposing of such, I was just hoping you had something better to offer back than 'I don't like it' and assertions that something is bad without ever explaining why. I have no idea why 'blameful postmortems' are bad because you never told me, you just say it is. Why should I change my mind in that case?
        ImPostingOnHN 2y ago

999900000999 2y ago

I don't know what exactly happened here, but Firebase has two defaults. Test access rules which auto expire and are insecure, or production rules which require auth. If you do something stupid, like keep ignoring the insecure warning and updating them so they don't expire, that's your fault. In no other industry do workers blame their tools.

prophesi 2y ago
The issue usually lies in there not being enough security rules in place, not in keeping insecure rules active. For instance, for the Arc incident which we were given more information on, it was due to not having a security rule in place to prevent unauthorized users from updating the user_id on Arc Boosts in the Firestore. Go into any other industry and hear when they say, "shoot yourself in the foot", and you've likely stumbled upon a situation where they blame their tools for making it too easy to do the wrong thing.
- 999900000999 2y ago
  If you don't setup any access rules in Firebase, by default it'll deny access. This means someone setup these rules improperly. Even if, you're responsible for the tools you use. We're a bunch of people getting paid 150k+ to type. It's not out of the question to read documentation and at a minimum understand how things work. That said I don't completely disagree with you, if Firebase enables reckless behavior maybe it's not a good tool for production...
  - prophesi 2y ago
    And I don't necessarily disagree either; good callout that it _was_ about improperly configured ACL's, I meant more that it wasn't related to keeping test rules alive. For 150k+ salaries, frontend dev salaries are generally a lot less than their backend counterparts. And scrappy startups might not have cash for competitive salaries or senior engineers. I think these are a few of the reasons why Firebase becomes dangerous.
    - 2y ago