5 ms·

> My goodness... This has nothing to do with postures and just bad security models when programming. Author here. Could you elaborate with some specifics?

wswope 5y ago
The person you’re replying to is being needlessly condescending, but I suspect what they’re getting at is that having a mindset of “what possible undesirable/malicious inputs are possible from this web form?” really precludes this scenario. Using unbounded text fields for a web form is a serious rookie move, as it’s a very obvious form of undesirable/malicious input. Point being, if you mess that up, what more subtle and dangerous inputs might you also be leaving yourself open to?
iammisc 5y ago
You should always validate input to a database. Data ought to be validated at the edge, which in this case is the http endpoints. You should not rely on internal services (a database) to do validation One of the dangers in switching to high level languages is that people have lost any sense of data size. In C you almost always specify a max string width because that is the easiest easy to deal with strings. While C has many shortcomings, forcing the responsible programmer to deal with string width is a good thing. Honestly as a stripe user, this sort of unvalidated input terrifies me. Stripe deals with money. All inputs ought to be validated. I figured the company would spend a lot of engineering time making sure data was cleaned and couldn't escape like this. Today it's a string width issue. Tomorrow it's a sql injection. I'm surprised stripe let you publish this.
- kam 5y ago
  What does string width have to do with SQL injection? You use parameterized queries, not just rely on your validation to reject quotes, right?
  - iammisc 5y ago
    I do... Yes. I follow best practices like parameterized queries, string width validation, password hashing via memory intensive hash functions etc. These are all basic beat practices. When a company admits to not doing one, it makes me worry about the others. This is the result of build fast and break things mentality which is toxic

wswope 5y ago

The person you’re replying to is being needlessly condescending, but I suspect what they’re getting at is that having a mindset of “what possible undesirable/malicious inputs are possible from this web form?” really precludes this scenario. Using unbounded text fields for a web form is a serious rookie move, as it’s a very obvious form of undesirable/malicious input. Point being, if you mess that up, what more subtle and dangerous inputs might you also be leaving yourself open to?

iammisc 5y ago

You should always validate input to a database. Data ought to be validated at the edge, which in this case is the http endpoints. You should not rely on internal services (a database) to do validation One of the dangers in switching to high level languages is that people have lost any sense of data size. In C you almost always specify a max string width because that is the easiest easy to deal with strings. While C has many shortcomings, forcing the responsible programmer to deal with string width is a good thing. Honestly as a stripe user, this sort of unvalidated input terrifies me. Stripe deals with money. All inputs ought to be validated. I figured the company would spend a lot of engineering time making sure data was cleaned and couldn't escape like this. Today it's a string width issue. Tomorrow it's a sql injection. I'm surprised stripe let you publish this.

kam 5y ago
What does string width have to do with SQL injection? You use parameterized queries, not just rely on your validation to reject quotes, right?
- iammisc 5y ago
  I do... Yes. I follow best practices like parameterized queries, string width validation, password hashing via memory intensive hash functions etc. These are all basic beat practices. When a company admits to not doing one, it makes me worry about the others. This is the result of build fast and break things mentality which is toxic