2 ms·
That sounds like BAD validation that needs fixing, not an excuse not to do any. Some US sites still won't let me in because (a) they insist that I must have a
by DamonHD 9y ago
That sounds like BAD validation that needs fixing, not an excuse not to do any.
Some US sites still won't let me in because (a) they insist that I must have a middle name or (b) screw up the hyphen in my surname.
Many sites and payroll systems assume that everyone has a surname. Never mind its character set and ordering.
Even if you don't make these assumptions you don't need to accept a binary gzipped GB of zeros or worse in a name input field.
- atemerev 9y agoDesigning a _good_ validation system (to reliably discriminate between "good" strings and "bad" strings, including all corner cases) is really hard, error-prone, not future-proof (standards change) and might be even theoretically impossible in some cases. Some basic sanity checks are useful, of course. But it is not a good idea to use input sanitization as the only (or even main) method of injection attacks prevention.
- DamonHD 9y agoI never said: 1) That it was easy to do right: that's why we get paid. 2) That it was an excuse not to do other checks elsewhere: defence in depth is key. Anyhow, I hope that we're really furiously agreeing.
- yetanotherjosh 9y ago> But it is not a good idea to use input sanitization as the only (or even main) method of injection attacks prevention Can you define what you mean by "input sanitization"? Because in my mind, a prepared statement is doing just that. You say what part is your SQL, what part is your user input, and you let the DB adapter sanitize the input to build the final statement. You aren't writing sanitization code yourself, you're leaving it up to a library, but that's still what's happening. Or do you have a different term for what's going when a prepared statement routine converts user input into SQL-safe strings?