Re:Don’t try to sanitize input – escape output
by ashearer on Thursday February 27, 2020 @12:51PM
(#22435705)
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.
Re:Don’t try to sanitize input – escape output
by zAy0LfpBZLC8mAC on Thursday February 27, 2020 @02:52PM
(#22437093)
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.
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.