3 ms·
I see where you are coming from but I disagree with your conclusions. I think the number of developers who would not have insecurely built a SQL string from us
by chucksmash 5y ago
I see where you are coming from but I disagree with your conclusions.
I think the number of developers who would not have insecurely built a SQL string from user input but for the language adding format strings is approximately zero.
By analogy, to me this argument seems like saying, "If a standard library contains a StringBuilder class that minimizes unnecessary allocations when constructing a String, it encourages developers to construct SQL strings manually and therefore makes them more likely to fall victim to SQL injection attacks, therefore we must not provide StringBuilder classes."
I don't imagine there are very many developers who are properly using parameterized queries only because it is inconvenient to concatenate strings.
- pron 5y ago> I think the number of developers who would not have insecurely built a SQL string from user input but for the language adding format strings is approximately zero. I'm not saying that format strings necessarily make injection vulnerabilities more common, but rather that, when added nowadays, they should be designed in a way that makes such vulnerabilities less common. If you're adding a feature that makes a potentially dangerous operation more convenient, you should also make it safer so that the convenience will help pull developers toward the safe option.
- drran 5y agoIMHO, your point is valid: currently, it's not possible to enforce a constraint on `format!()` arguments, AFAIK, so we cannot say that all arguments to that format string, which will be used in that API, must implement SafeHTML trait or SafeSQL trait. You should create a ticket or RFC for the problem.