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 <[email protected]> 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.