4 ms·

> Code should ideally be correct and fail-safe; deal gracefully with bad input, ensure correct output, at all levels. Ideally. NO! If you get bad input, you s

> Code should ideally be correct and fail-safe; deal gracefully with bad input, ensure correct output, at all levels. Ideally. NO! If you get bad input, you should fail, loudly. Anything else is a recipe for disaster. (Not as in "crash the whole system", of course, but as in "reject the request".)

eythian 7y ago
This tends to leads to systems that don't work and die on real-world edge cases.
- zAy0LfpBZLC8mAC 7y ago
  No, it doesn't. That is what "accept anything" programming leads to. The idea that "accepting all the inputs" somehow gives you an advantage is an illusion: If the semantics of some input are not well-defined, then the only thing you gain by accepting it anyway are hard to debug interoperability problems and vulnerabilities. When some input is not well-defined accoridng to the spec, then your interpretation is just a random guess, and the next developer will make a different random guess as to what that input means, and so an interoperability problem and potential vulnerability is born. If you reject the invalid input, you will notice the error and thus fix the source of the invalid input to produce input for which the semantics are actually well-defined.
  - ashearer 7y ago
    This sounds good in theory, but I'll give a counterexample. Requirement: Name input box. Implementation: We'll sanitize the input by rejecting any characters likely to be dangerous if mishandled, like single quotes, or anything else we don't immediately imagine to be useful. If a character turns out to be needed later, that's no problem. We'll just change the list. Security audit: Passes Later customer complaint: I can't sign up! — J. O'Brien Dev team: Sorry, too bad. We'd have to re-audit everything and possibly modify code to allow your last name, because there might be code somewhere that relies on the original sanitization for security. That was the point of sanitizing on input, after all. If you want to sign up, it would be easiest for us if you would just change your name.
    - zAy0LfpBZLC8mAC 7y ago
      I think you misunderstood my point. I am not saying that you should reject valid (that is: semantically meaningful) input, but that if you are confronted with semantically meaningless input, you should reject it rather than garble it so that it gains some random meaning. So: Name input field, value "J. O'Brien": accept JSON parameter, value "{foo:bar}": reject The context was the idea that you should gracefully accept bad input. If your code considers "J. O'Brien" bad input for a name, then that's the problem, not that it doesn't accept bad input.
      - ashearer 7y ago
        Yes, I completely agree in the above case. The JSON input has a well-defined format and input validation should reject it outright. The issue is that when developers hear they should "reject bad input" in order to avoid vulnerabilities, they often interpret it as a call to reject any user input that isn't already known to be good. Since user inputs are often free text, like the name field, they wind up forbidding any input they hadn't specifically imagined, which doesn't align with any particular recipient's actual data requirement. It creates false-negative edge cases while only providing illusory help against vulnerabilities.
        zAy0LfpBZLC8mAC 7y ago
        I mean, I generally agree, but I think it's already problematic to frame it as "user input that isn't already known to be good". Because "J. O'Brien" is known to be good. The problem is that anyone thinks in the first place that some semantically meaningful input value for some reason is not good.
trashbindigger 7y ago
I’m confused because I agree with this comment, but your other comments mentioned: > "sanitizing input" is plain nonsense > "Unsafe input" is not a thing. Have you ever used hand sanitizer? The point of hand sanitizer is to reject infectious diseases outright.... you know, so they don’t get IN your body. You seem to have adopted a narrowly defined sense of sanitization which does not include “mercilessly discard/destroy”.
- zAy0LfpBZLC8mAC 7y ago
  > The point of hand sanitizer is to reject infectious diseases outright.... you know, so they don’t get IN your body. There is no such thing as "infectious input data". > You seem to have adopted a narrowly defined sense of sanitization which does not include “mercilessly discard/destroy”. None of the dictionaries I just checked support such a definition. They are all about "changing something to be more sane/sanitary/pleasant/acceptable/...". Also, mind you a hand sanitizer doesn't destroy your hand, it destroys microbes, in order to make your hand sanitary, so as to enable you to continue using your hand instead of rejecting/disarding it. Which is exactly the kind of thing you should not ever do with input data.

eythian 7y ago

This tends to leads to systems that don't work and die on real-world edge cases.

zAy0LfpBZLC8mAC 7y ago
No, it doesn't. That is what "accept anything" programming leads to. The idea that "accepting all the inputs" somehow gives you an advantage is an illusion: If the semantics of some input are not well-defined, then the only thing you gain by accepting it anyway are hard to debug interoperability problems and vulnerabilities. When some input is not well-defined accoridng to the spec, then your interpretation is just a random guess, and the next developer will make a different random guess as to what that input means, and so an interoperability problem and potential vulnerability is born. If you reject the invalid input, you will notice the error and thus fix the source of the invalid input to produce input for which the semantics are actually well-defined.
- ashearer 7y ago
  This sounds good in theory, but I'll give a counterexample. Requirement: Name input box. Implementation: We'll sanitize the input by rejecting any characters likely to be dangerous if mishandled, like single quotes, or anything else we don't immediately imagine to be useful. If a character turns out to be needed later, that's no problem. We'll just change the list. Security audit: Passes Later customer complaint: I can't sign up! — J. O'Brien Dev team: Sorry, too bad. We'd have to re-audit everything and possibly modify code to allow your last name, because there might be code somewhere that relies on the original sanitization for security. That was the point of sanitizing on input, after all. If you want to sign up, it would be easiest for us if you would just change your name.
  - zAy0LfpBZLC8mAC 7y ago
    I think you misunderstood my point. I am not saying that you should reject valid (that is: semantically meaningful) input, but that if you are confronted with semantically meaningless input, you should reject it rather than garble it so that it gains some random meaning. So: Name input field, value "J. O'Brien": accept JSON parameter, value "{foo:bar}": reject The context was the idea that you should gracefully accept bad input. If your code considers "J. O'Brien" bad input for a name, then that's the problem, not that it doesn't accept bad input.
    - ashearer 7y ago
      Yes, I completely agree in the above case. The JSON input has a well-defined format and input validation should reject it outright. The issue is that when developers hear they should "reject bad input" in order to avoid vulnerabilities, they often interpret it as a call to reject any user input that isn't already known to be good. Since user inputs are often free text, like the name field, they wind up forbidding any input they hadn't specifically imagined, which doesn't align with any particular recipient's actual data requirement. It creates false-negative edge cases while only providing illusory help against vulnerabilities.
      - zAy0LfpBZLC8mAC 7y ago
        I mean, I generally agree, but I think it's already problematic to frame it as "user input that isn't already known to be good". Because "J. O'Brien" is known to be good. The problem is that anyone thinks in the first place that some semantically meaningful input value for some reason is not good.

trashbindigger 7y ago

I’m confused because I agree with this comment, but your other comments mentioned: > "sanitizing input" is plain nonsense > "Unsafe input" is not a thing. Have you ever used hand sanitizer? The point of hand sanitizer is to reject infectious diseases outright.... you know, so they don’t get IN your body. You seem to have adopted a narrowly defined sense of sanitization which does not include “mercilessly discard/destroy”.

zAy0LfpBZLC8mAC 7y ago
> The point of hand sanitizer is to reject infectious diseases outright.... you know, so they don’t get IN your body. There is no such thing as "infectious input data". > You seem to have adopted a narrowly defined sense of sanitization which does not include “mercilessly discard/destroy”. None of the dictionaries I just checked support such a definition. They are all about "changing something to be more sane/sanitary/pleasant/acceptable/...". Also, mind you a hand sanitizer doesn't destroy your hand, it destroys microbes, in order to make your hand sanitary, so as to enable you to continue using your hand instead of rejecting/disarding it. Which is exactly the kind of thing you should not ever do with input data.