5 ms·

1M order exposed and 200k customer and workers data exposed just because an AuthKey is allowed to query all customer data instead of user specific data. this m

1M order exposed and 200k customer and workers data exposed just because an AuthKey is allowed to query all customer data instead of user specific data. this means most likely a junior developer built this service, and on top graphQL is used which is built relational first / security is one step away. it sucks that companies grow fast in the tech scene, try to make their wealth using technology without really understanding it.

amelius 5y ago
Growth hacking 101: ignore security; it's never too late to work on security; the worst that can happen is some wrist slapping; security is a luxury problem.
- username_my1 5y ago
  I mean with graphQL as I mentioned it feels like you have to bend it that way to load all data without relationships also why on earth do you need to expose your suppliers (sendgrid) api keys to the frontend it's not about ignoring security as if it's extra work, it's about not being qualified enough to do a reasonable job. security is hard, but this is going out of your way to expose your system.
  - ratww 5y ago
    IMO this is a cultural problem. Coupled with a general lack of experience of majority of people working in our industry. People learn how to do certain programming tasks in one way, and instead of trying to fully understand "what" and "why" they're doing it, they just keep doing it. This approach works fine in a computer class, or in internships, but it breaks down when comes to writing secure apps. It is similar with SQL injection: using prepared queries is not really difficult. I'd even claim that it's easier and simpler to write compared to string concatenation. But "knowing" about them takes time, curiosity and preparation. But making queries via string concatenation is how people used to learn. Another thing is over-engineering (the wrong kind): it is more difficult to write tens of classes rather than doing what the task requires, but some people still do it because that's how they learned to program. There are no shortcuts, unfortunately. So far we've solved this partially by using slogans: "Just use BCrypt" was a popular one a few years ago. But honestly I don't think this is enough. We need more mentorship (for the beginners) and more peer reviews (for the experienced).
    - jrumbut 5y ago
      I wonder frequently if we've reached the point where we need a license exam to be able to work on web apps that handle money or store personal data.
      - bumby 5y ago
        NCEES briefly toyed with the idea of a Professional Engineer license for software but it went away due to lack of interest. I think it would take the initiative of employers or regulators to make it happen, and the former is not likely since it works against their own incentives (it effectively gives more leverage to those with the license)
  - brazzy 5y ago
    > also why on earth do you need to expose your suppliers (sendgrid) api keys to the frontend It's the other way round: you need to make sure not to expose sensitive parts of your configuration to the client. That's an extra step you can forget about (or fail to consider in the first place).
- joshspankit 5y ago
  Excellent comment and the current business structures have made it even worse: If the security incident is actually really terrible, simply fold the publicly-facing company and pivot with all the IP in the IP company. Maybe white-label it, or maybe just wait a little and start the exact same type of company under a new brand. Only the papers get a slap on the wrist.

amelius 5y ago

Growth hacking 101: ignore security; it's never too late to work on security; the worst that can happen is some wrist slapping; security is a luxury problem.

username_my1 5y ago
I mean with graphQL as I mentioned it feels like you have to bend it that way to load all data without relationships also why on earth do you need to expose your suppliers (sendgrid) api keys to the frontend it's not about ignoring security as if it's extra work, it's about not being qualified enough to do a reasonable job. security is hard, but this is going out of your way to expose your system.
- ratww 5y ago
  IMO this is a cultural problem. Coupled with a general lack of experience of majority of people working in our industry. People learn how to do certain programming tasks in one way, and instead of trying to fully understand "what" and "why" they're doing it, they just keep doing it. This approach works fine in a computer class, or in internships, but it breaks down when comes to writing secure apps. It is similar with SQL injection: using prepared queries is not really difficult. I'd even claim that it's easier and simpler to write compared to string concatenation. But "knowing" about them takes time, curiosity and preparation. But making queries via string concatenation is how people used to learn. Another thing is over-engineering (the wrong kind): it is more difficult to write tens of classes rather than doing what the task requires, but some people still do it because that's how they learned to program. There are no shortcuts, unfortunately. So far we've solved this partially by using slogans: "Just use BCrypt" was a popular one a few years ago. But honestly I don't think this is enough. We need more mentorship (for the beginners) and more peer reviews (for the experienced).
  - jrumbut 5y ago
    I wonder frequently if we've reached the point where we need a license exam to be able to work on web apps that handle money or store personal data.
    - bumby 5y ago
      NCEES briefly toyed with the idea of a Professional Engineer license for software but it went away due to lack of interest. I think it would take the initiative of employers or regulators to make it happen, and the former is not likely since it works against their own incentives (it effectively gives more leverage to those with the license)
- brazzy 5y ago
  > also why on earth do you need to expose your suppliers (sendgrid) api keys to the frontend It's the other way round: you need to make sure not to expose sensitive parts of your configuration to the client. That's an extra step you can forget about (or fail to consider in the first place).
joshspankit 5y ago
Excellent comment and the current business structures have made it even worse: If the security incident is actually really terrible, simply fold the publicly-facing company and pivot with all the IP in the IP company. Maybe white-label it, or maybe just wait a little and start the exact same type of company under a new brand. Only the papers get a slap on the wrist.