3 ms·

> Developers: Sanitize user input No, don't sanitize user input. Don't trust it, which is a big difference. Use bound parameters and this problem goes away.

acdha 6y ago
A better answer is both not trusting it and validating it: parameters prevent data from being interpreted as code but validation is also important because allowing unexpected inputs could lead to other vulnerabilities (e.g. XSS in an error message or a partially-generated page) or complications when making changes in the future if you learn that common clients have come to rely on your sanitization logic cleaning up their requests.
- deleted 6y ago
  [deleted]
- bcrosby95 6y ago
  Please no. Trying to validate your input for any format that currently exists or may exist in the future is really wrong. You need to handle this at the edges - for SQL this is using prepared statements, for XSS its about using a framework that makes the correct choice (default escape HTML entities). Anything else is madness. Of course, if you're dealing with legacy systems you might have to do something tragic like not allow people to put quotes in passwords.
  - acdha 6y ago
    I think you might have misunderstood my comment even on the second reply after the ruder version you deleted: validation at edge is exactly what I was suggesting. If you're writing your code assuming a numeric ID, using placeholders means that it won't be exploitable if someone submits a non-numeric value but you're still at risk as described and likely other problems. If you validate it immediately and send an HTTP 400 for anything which isn't a valid number in whatever range you support, you don't have to worry about later finding out that someone came up with a clever way to do XSS, log splitting, etc. attacks even if they couldn't get at the database directly.
nuclear_eclipse 6y ago
Sanitize, normalize, and distrust. All three cover different use cases.

acdha 6y ago

A better answer is both not trusting it and validating it: parameters prevent data from being interpreted as code but validation is also important because allowing unexpected inputs could lead to other vulnerabilities (e.g. XSS in an error message or a partially-generated page) or complications when making changes in the future if you learn that common clients have come to rely on your sanitization logic cleaning up their requests.

deleted 6y ago
[deleted]
bcrosby95 6y ago
Please no. Trying to validate your input for any format that currently exists or may exist in the future is really wrong. You need to handle this at the edges - for SQL this is using prepared statements, for XSS its about using a framework that makes the correct choice (default escape HTML entities). Anything else is madness. Of course, if you're dealing with legacy systems you might have to do something tragic like not allow people to put quotes in passwords.
- acdha 6y ago
  I think you might have misunderstood my comment even on the second reply after the ruder version you deleted: validation at edge is exactly what I was suggesting. If you're writing your code assuming a numeric ID, using placeholders means that it won't be exploitable if someone submits a non-numeric value but you're still at risk as described and likely other problems. If you validate it immediately and send an HTTP 400 for anything which isn't a valid number in whatever range you support, you don't have to worry about later finding out that someone came up with a clever way to do XSS, log splitting, etc. attacks even if they couldn't get at the database directly.

nuclear_eclipse 6y ago

Sanitize, normalize, and distrust. All three cover different use cases.