4 ms·

This is bad advice. Definitely sanitize on input, then escape on output. You should never be knowingly storing unsafe input.

by skyzyx 7y ago

e12e 7y ago
Actually, rather than sanitize input, I would recommend whitelist and reject in most cases. ID should be an integer, but you get a string with spaces around an integer? - error out. There's html in your text input? Error out. In the vast majority of cases you control the client (web form) - anything "surprising" will then be an error - or worse; malicious. In the case of a json service, if the client doesn't submit valid json for your schema / api - error out.
- e12e 7y ago
  TFA touches on this with validation - validation is ux improvement - help the user submit only valid data. At that point there should be no proper use-case for invalid data to be submitted - hence reject, not sanitize and insert.
- duncans 7y ago
  > There's html in your text input? - error out How do you detect HTML? Less-than/greater-than signs? Users are now banned from entering Less-than/greater-than signs?
  - hombre_fatal 7y ago
    I once registered for a forum to ask a question, but they had it configured so new users couldn't submit URLs, probably to deal with spam. Their solution was to reject posts that contained what looked like URLs which means any time you don't put a space after a period, it's probably a URL. Like "That is fine.Pizza is good." -> http://fine.pizza http://fine.pizza detected, post rejected But it gets worse. I had a code block in my post and it was also detecting URLs in my code. `console.log` -> URL detected!
  - e12e 7y ago
    Good point. I guess I'm in agreement with tfa here - if special entities are ok, escape output. I don't think I want to allow a greater than sign in a "first name" field, but it might be perfectly valid in a text field. And if that field is text, not hypertext, escaping output seems sane. Maybe only where html is expected - say in the html part of an email, while the text part just uses a proper encoding.
zAy0LfpBZLC8mAC 7y ago
"Unsafe input" is not a thing.

This is bad advice. Definitely sanitize on input, then escape on output. You should never be knowingly storing unsafe input.

by skyzyx 7y ago

This is bad advice. Definitely sanitize on input, then escape on output. You should never be knowingly storing unsafe input.

e12e 7y ago

Actually, rather than sanitize input, I would recommend whitelist and reject in most cases. ID should be an integer, but you get a string with spaces around an integer? - error out. There's html in your text input? Error out. In the vast majority of cases you control the client (web form) - anything "surprising" will then be an error - or worse; malicious. In the case of a json service, if the client doesn't submit valid json for your schema / api - error out.

e12e 7y ago
TFA touches on this with validation - validation is ux improvement - help the user submit only valid data. At that point there should be no proper use-case for invalid data to be submitted - hence reject, not sanitize and insert.
duncans 7y ago
> There's html in your text input? - error out How do you detect HTML? Less-than/greater-than signs? Users are now banned from entering Less-than/greater-than signs?
- hombre_fatal 7y ago
  I once registered for a forum to ask a question, but they had it configured so new users couldn't submit URLs, probably to deal with spam. Their solution was to reject posts that contained what looked like URLs which means any time you don't put a space after a period, it's probably a URL. Like "That is fine.Pizza is good." -> http://fine.pizza http://fine.pizza detected, post rejected But it gets worse. I had a code block in my post and it was also detecting URLs in my code. `console.log` -> URL detected!
- e12e 7y ago
  Good point. I guess I'm in agreement with tfa here - if special entities are ok, escape output. I don't think I want to allow a greater than sign in a "first name" field, but it might be perfectly valid in a text field. And if that field is text, not hypertext, escaping output seems sane. Maybe only where html is expected - say in the html part of an email, while the text part just uses a proper encoding.

zAy0LfpBZLC8mAC 7y ago

"Unsafe input" is not a thing.