Is character restriction ever a safe mechanism against code injection / better than input sanitisation?

Question

Many services still restrict the special characters allowed in passwords and similar with the argument that it prevents injection attacks. Now, there are many good arguments against this such as avoiding unnecessary obstructions, character choice increasing the security of chosen passwords, and so on. Here, I am only interested in the following argument:

Any system that checks whether a password conforms with character restrictions is potentially subject to injection attacks itself. If you do not understand your system well enough to prevent code injection, this is a potential security hole. Therefore you cannot rely on restricting special characters to fully prevent injection attacks. (Mind the fully: Obviously, injection attacks after the special-character filter are prevented.)

A variant of this argument comparing character restriction and input sanitization would be:

Whether you apply sanitization or character restriction to user input, it should be the very first thing you do. Both of these mechanisms are possibly subject to code injection themselves, but if you do not understand your system well enough to make these systems safe from code injection, you can also not say which one is better. Therefore, there is no reason to prefer character restriction over sanitisation. (Since this is about vulnerabilities in the mechanism and not imperfection of its result, applying both yields no benefit.)

Are these arguments valid or is there something I am missing?

Answer 1

Is character restriction ever a safe mechanism against code injection

If character restrictions is a sufficiently secure protection against code injection depends on the specific implementations and what exactly it is intended to prevent. If any characters suitable for injection are still allowed, then the restriction is obviously not sufficient. Which characters need to be disallowed thus clearly depend on the context in which the input is used.

Properly done it can be sufficiently secure, improperly done it is insecure. Applications are complex though and evolve, so what was once a suitable restriction might no longer be sufficient after changes to the application. So character restrictions should not be seen as finally done once implemented but it should be reevaluated if the application changes and the expectations on the input and how it will be processed should be clearly communicated throughout the application.

Is character restriction ... better than input sanitisation?

Input sanitization has its own problems. Like character restriction it relies on specific assumptions on how the input should look like and enforces these assumptions. These assumptions are based on how the input will be processed inside the application. Like with character restrictions the assumptions might be wrong from start or might turn wrong later if the application changes. Wrong sanitization might even change the input in a way that it introduces security issues which were not there before.

Since this is about vulnerabilities in the mechanism and not imperfection of its result, applying both yields no benefit.

It is better to combine input validation (like character restrictions) and input sanitization, specifically because in practice one cannot rely on the perfection of either of these mechanisms. It should be done in the right order though, i.e. first sanitize and then validate the input directly where it gets used to prevent issues from wrong sanitization. Validating the input before use against the context specific expectations in various parts of the code is a good idea too, i.e. don't rely too much on the first sanitization and validation done correctly.

Moreover, one should tackle the main problem of injection attacks: the missing separation between data and code. Such seperation can be enforced within HTML by disallowing inline script using Content-Security-Policy, or within SQL by using parameterized queries instead of building the query by string concatenation of SQL statements with user input.