> On 22 Jun 2021, at 20:13, Craig Francis <cr...@craigfrancis.co.uk> wrote: > > On Tue, 22 Jun 2021 at 09:59, Stephen Reay <php-li...@koalephant.com > <mailto:php-li...@koalephant.com>> wrote: > So I just want to make sure I understand the progression on this so far. It > started out with people wanting a way to check that a string was a literal > string, in code somewhere, and does not come from user input. Ok makes sense. > The name makes sense too. > > > > The primary reason was never just to define literal strings, the intention > has always been to create a practical, implementable solution to address the > issue of Injection Vulnerabilities (SQl/HTML/CLI/etc). >
Preventing injection vulnerabilities may be your goal but I’m talking about the intended behaviour of this one function. Your original email says this: >> Distinguishing strings from a trusted developer from strings that may be >> attacker controlled If you feel that somehow doesn’t mean the same as "check that a string was a literal string, in code somewhere, and does not come from user input”, then we need to crack open a dictionary and work out which words one of us doesn’t know the meaning of. > The name `is_literal()` has always just been a placeholder, it came up when I > first started looking at this problem because that was the most obvious thing > I knew we could anchor around. (Unfortunately I think it was easy to make > assumptions based solely on that name, rather than focussing on the issue it > is meant to address). > > So, we cannot look for literals only - while it was part of the solution, it > was very much incomplete. Bearing in mind, there is considerable amount of > existing code and tutorials out there which include integers in their > SQL/HTML/CLI/etc, and they are perfectly safe in doing so. Making a solution > which does not support integers is not going to be adopted/used because the > task of rewriting and changing everything, for no benefit, will not be > considered by developers. > There is a considerable amount of existing code that includes strings in SQL, HTML without danger too. Plenty of string values are fine, and plenty of integer values are fine. That doesn’t mean we should just blindly trust a value that came from the user, just because it’s a number. The saying goes “never trust user input” not “never trust user input unless it’s a number”. > Likewise, a lot of code already builds SQL/HTML/CLI/etc strings via > concatenation and sprintf(), and forcing everyone to use a query builder is > likely to cause most people to not even consider using this. > If they won’t adopt an existing solution to the problem why would they adopt this? You’ve said very recently that this is not intended to be used directly by most developers, and instead used within libraries and frameworks. It seems a little weird to then make concessions that will defeat the stated goal, in the name of adoption. > It's all well thinking of one thing that might theoretically/idealistically > solve the issue, but it also needs to have a plan on how this will be > practically implemented and used by developers (which this has done). > Having a plan for how to implement something doesn’t help much when the thing you’re implementing deliberately ignores a specific type of ‘untrusted’ input..
