Re: [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack

Thanks for the feedback Anthony, This feature specifically addresses the points you raise; the feature allows parameterized queries constructed with structural parts of the query inserted from configuration variables, so long as the resulting query is a safe-const as defined by this RFC. If you can come up with an example of a query that either (a) is vulnerable to a SQL injection attack and this feature wrongly does not detect it as such or (b) a query that cannot be expressed using parameterized queries where the parameter is a safe-const as defined by this RFC, I'd be genuinely interested to take a look. Hope that clarifies, Matt > On Aug 6, 2015, at 14:34, Anthony Ferrara <ircmaxell@gmail.com> wrote: > > Matt, > >> You are of course welcome to disagree with the overwhelming body of security >> advice that parameterized queries are the correct, secure way to prevent SQL >> injection. In that case, you only need to not enable this feature. This >> feature is off-by-default, and only attempts to help secure webapplications >> and webdevelopers who do (or are required, for example by PCI compliance >> standards) to adopt this security-best-practice to ensure that they do so >> systematically across their entire website. > > You seem to misunderstand me. I'm *not* saying that you shouldn't use > parameterized queries. Nor that they are not one of the best tools > available. I am simply pointing out that they are not a sure-fire > one-stop solution. There is a lot more that goes into it than simply > using prepare/bind. As indicated by the two cases I talked about > (structural elements not being supported and implementation quirks) as > well as others (DOS attacks from wildcards in malformed query > parameters, type validation, etc). This is not to say that we should > avoid PQ, but that we should recognize that it's not enough to just > use one thing and forget about everything else. > > Anthony > > PS: w3schools is NOT w3c. And their content is probably the single > largest source of security vulnerabilities for PHP, so citing them in > a security discussion is more than a little ironic.