On Wed, 16 Jun 2021 at 9:13 pm, Dik Takken <dik.tak...@gmail.com> wrote:
> On 16-06-2021 19:24, Craig Francis wrote: > > Matthew Brown wants to support integer values, simply because so much > code > > already includes them, and I cannot find a single way that integers alone > > can cause issues from an Injection Vulnerability point of view. > > […] > > Expanding the 'literal' concept to other types than just strings > sounds like a good idea. However, limiting it to just integers sounds a > little arbitrary. If people want to insert a float or boolean into their > query and they are happy with the way those are coerced into strings, why > not allow it? > Applying this to floats and booleans might be dangerous, as what’s put in might not be what comes out (I want to keep the scope as limited as possible). is_literal can be used for strings because we can flag what’s user and what’s developer defined, and with Matthew’s request, it could do integers (because an integer value alone is not inherently risky, and it’s already used a lot). However because of things like true/TRUE getting converted to "1", we can’t apply the same certainty to floats and booleans - it wouldn’t be a consistent secure approach. > Which leads us to the name, because "is_literal" may be, uh, too literal. > > So can we come up with something better? > > Throwing in another idea: is_hard_coded(). > I’d be a little hesitant on the name ‘is_hard_coded’, if we allow integers, that means that it’s no longer strictly hard coded, and might get confusing.
