4 ms·

> you should NEVER TRUST USER INPUT That is not clear at all and pretty useless. What does it mean? I should not accept any user input at all? > strip everyt

> you should NEVER TRUST USER INPUT That is not clear at all and pretty useless. What does it mean? I should not accept any user input at all? > strip everything that is not needed That does not always work. What if I have a comment form that should accept any characters?

blastrat 10y ago
I'm not being a smartaleck, but "you shouldn't be writing code" with your attitude/approach. "NEVER trust user input" is an important security mantra to learn all on its own, like "wipe your butt/wash your hands" is in another context. The guy is writing a valid point on Hacker(!) News. People writing comments on HN (especially to summarize a takeaway from a longer form article) are not required to accurately recapitulate entire dossiers of how to process input. It is completely valid to say "you should never trust user input". Somebody who is looking to make that "actionable" or "clear and pretty useful" can very very easily google the phrase and will turn up a lot of useful answers and information. This is what is meant by the idea that the simplicity of the iPhone UI and/or automated IDEs has created a generation of helplessness and entitlement. The good advice remains good advice: you should never trust user input. If you can't turn that into sound advice from Hacker News, your options become limited to, nobody should trust the code you write, you shouldn't write code, or you shouldn't read hacker news for advice. But the idea that people need to write what you personally need to hear or they shouldn't write comments? that's nuts. Could I have written a more useful comment to you and to the community? I'll tell you this, I did think about it, and this my best shot at what I thought you and the community could benefit from! There used to be a guy on usenet news who posted all sorts of stuff, and had the name of his company in his .sig line, and he included the phrase "these ARE the opinions of my company" instead of that boring old boilerplate "none of the opinions I express are..."
- adrianratnapala 10y ago
  NEVER trust user input" is an important security mantra to learn all on its own, like "wipe your butt/wash your hands" is in another context. Even the contexts are not so different. DNA is an information carrier, life is an information system, hygine and the immune system are information security mechanisms. Though I am not sure who the user is in this analogy.
krapp 10y ago
>What does it mean? I should not accept any user input at all? No, it means you should never assume that user data is safe, or even sane. Assume, rather, that everything every user is sending you is malicious, all the time, and write your code accordingly. >. What if I have a comment form that should accept any characters? First, you probably shouldn't, because your database and HTML should be using explicit character encodings, so a comment form that accepts anything doesn't make a lot of sense. How are you expecting to deal with "any characters"? What happens when they paste in a binary blob, or javascript code? Secondly, assuming you want to do that, you still shouldn't trust the data. Add it to the database using parameterized queries, escape it when rendering, never mix it in to javascript variables and never serialize it into a format designed to unserialize executable objects. It's not an unreasonable burden to expect web developers to at least be aware and code defensively. Especially with PHP.
- dmix 10y ago
  > it means you should never assume that user data is safe, or even sane I'm curious if Haskell's purity helps developers focus on this issue and therefore makes it easier to mitigate. Given that all user input/state already has to be handled carefully (for ex: with monads). It will be obvious in the codebase which parts need to be zero'd in on for possible attack vectors.
  - sitharus 10y ago
    Haskell's web frameworks help, but it's nothing to do with purity. In fact any web framework can do this, you segregate user-supplied data and ensure it can never be supplied to an untrusted function without explicit cleaning. Perl and Ruby have included this as a 'tainted' flag, many functions cannot be called with a tainted string.
  - MustardTiger 10y ago
    >I'm curious if Haskell's purity helps developers focus on this issue and therefore makes it easier to mitigate No, haskell's type system does, not its purity. >Given that all user input/state already has to be handled carefully (for ex: with monads) What? Monads are not some mythical beast, there is nothing "handled carefully" about it. A monad is just a general interface.
DavidWanjiru 10y ago
You're confusing "trust" with "use," which appears to be the cause of your apparent bewilderment. I could be wrong, however. Suppose you were handling snakes. Some snakes are not poisonous, and don't need to handled with the care you'd handle, say, a black mamba with. However, you are being advised to treat every snake you encounter as though it was the most poisonous snake known, and apply every care that you normally apply to snakes that you know are poisonous. Will you handle the snakes? Yes, you're a snake handler, remember? But you handle all of them like they are deadly, even the ones you "know" to not be deadly.
- sundvor 10y ago
  On a side note; snakes are venomous, not poisonous. Your point is well taken though - and I've come closer than I'd like to a few tiger snakes in my area. User input ought to be treated with the same kind of respect, although in terms of user input the option of giving them a wide birth isn't always as practical.

blastrat 10y ago

I'm not being a smartaleck, but "you shouldn't be writing code" with your attitude/approach. "NEVER trust user input" is an important security mantra to learn all on its own, like "wipe your butt/wash your hands" is in another context. The guy is writing a valid point on Hacker(!) News. People writing comments on HN (especially to summarize a takeaway from a longer form article) are not required to accurately recapitulate entire dossiers of how to process input. It is completely valid to say "you should never trust user input". Somebody who is looking to make that "actionable" or "clear and pretty useful" can very very easily google the phrase and will turn up a lot of useful answers and information. This is what is meant by the idea that the simplicity of the iPhone UI and/or automated IDEs has created a generation of helplessness and entitlement. The good advice remains good advice: you should never trust user input. If you can't turn that into sound advice from Hacker News, your options become limited to, nobody should trust the code you write, you shouldn't write code, or you shouldn't read hacker news for advice. But the idea that people need to write what you personally need to hear or they shouldn't write comments? that's nuts. Could I have written a more useful comment to you and to the community? I'll tell you this, I did think about it, and this my best shot at what I thought you and the community could benefit from! There used to be a guy on usenet news who posted all sorts of stuff, and had the name of his company in his .sig line, and he included the phrase "these ARE the opinions of my company" instead of that boring old boilerplate "none of the opinions I express are..."

adrianratnapala 10y ago
NEVER trust user input" is an important security mantra to learn all on its own, like "wipe your butt/wash your hands" is in another context. Even the contexts are not so different. DNA is an information carrier, life is an information system, hygine and the immune system are information security mechanisms. Though I am not sure who the user is in this analogy.

krapp 10y ago

>What does it mean? I should not accept any user input at all? No, it means you should never assume that user data is safe, or even sane. Assume, rather, that everything every user is sending you is malicious, all the time, and write your code accordingly. >. What if I have a comment form that should accept any characters? First, you probably shouldn't, because your database and HTML should be using explicit character encodings, so a comment form that accepts anything doesn't make a lot of sense. How are you expecting to deal with "any characters"? What happens when they paste in a binary blob, or javascript code? Secondly, assuming you want to do that, you still shouldn't trust the data. Add it to the database using parameterized queries, escape it when rendering, never mix it in to javascript variables and never serialize it into a format designed to unserialize executable objects. It's not an unreasonable burden to expect web developers to at least be aware and code defensively. Especially with PHP.

dmix 10y ago
> it means you should never assume that user data is safe, or even sane I'm curious if Haskell's purity helps developers focus on this issue and therefore makes it easier to mitigate. Given that all user input/state already has to be handled carefully (for ex: with monads). It will be obvious in the codebase which parts need to be zero'd in on for possible attack vectors.
- sitharus 10y ago
  Haskell's web frameworks help, but it's nothing to do with purity. In fact any web framework can do this, you segregate user-supplied data and ensure it can never be supplied to an untrusted function without explicit cleaning. Perl and Ruby have included this as a 'tainted' flag, many functions cannot be called with a tainted string.
- MustardTiger 10y ago
  >I'm curious if Haskell's purity helps developers focus on this issue and therefore makes it easier to mitigate No, haskell's type system does, not its purity. >Given that all user input/state already has to be handled carefully (for ex: with monads) What? Monads are not some mythical beast, there is nothing "handled carefully" about it. A monad is just a general interface.

DavidWanjiru 10y ago

You're confusing "trust" with "use," which appears to be the cause of your apparent bewilderment. I could be wrong, however. Suppose you were handling snakes. Some snakes are not poisonous, and don't need to handled with the care you'd handle, say, a black mamba with. However, you are being advised to treat every snake you encounter as though it was the most poisonous snake known, and apply every care that you normally apply to snakes that you know are poisonous. Will you handle the snakes? Yes, you're a snake handler, remember? But you handle all of them like they are deadly, even the ones you "know" to not be deadly.

sundvor 10y ago
On a side note; snakes are venomous, not poisonous. Your point is well taken though - and I've come closer than I'd like to a few tiger snakes in my area. User input ought to be treated with the same kind of respect, although in terms of user input the option of giving them a wide birth isn't always as practical.