As for the sanitisation, it can take many forms. Either characters that don’t usually appear in the context for that field (in terms of names, you can usually scrub most parentheses, more than one hyphen in a row etc) can be removed; copy it to a known encoded field such as unicode to get rid of characters with unusual properties; and making sure bounds are enforced to avoid overflows.
It should mean that your data is exactly that - raw data, and not commands or operands for the interpreter to act upon.
I don’t disagree, but throwing out the concept of prepared statements and parameterisation to someone who has asked for an explanation of the Bobby Tables jokes is a bit heavy going.
Spot on.
As for the sanitisation, it can take many forms. Either characters that don’t usually appear in the context for that field (in terms of names, you can usually scrub most parentheses, more than one hyphen in a row etc) can be removed; copy it to a known encoded field such as unicode to get rid of characters with unusual properties; and making sure bounds are enforced to avoid overflows.
It should mean that your data is exactly that - raw data, and not commands or operands for the interpreter to act upon.
Parameterisation entirely solves the problem without needing to sanitise the string
I don’t disagree, but throwing out the concept of prepared statements and parameterisation to someone who has asked for an explanation of the Bobby Tables jokes is a bit heavy going.
Not entirely (I recall seeing some obscure CVEs some years ago), but it’s a hell of a lot better than what some coders try to get away with.