Hi Anthony, Julien, Yasuo,
I have been reading your conversation with great interest.
But I would urge you to see Matts suggestion as a simple addition to the language (it's simpler
than my suggestion), where his RFC seems to have already addressed your concerns (and he seems to
have a working proof of concept).
Personally I would like to see any one of these solutions being added to the core language, as there
are far too many PHP programmers making ridiculous mistakes that the core language can be (and
should be) identifying. That said, I am still biased to my suggestion, which also tries to consider
other problems like XSS.
But anyway...
Take the code below, it is obviously wrong, but it executes without any complaints, and unless
someone is checking every line of code that is written (note: PHP is doing so already), then the
developer will just move on without thinking anything is wrong:
http://php.net/manual/en/pdo.exec.php
$dbh->exec("DELETE FROM fruit WHERE colour =
'{$_GET['colour']}'");
Over the years I've heard many people say things like "use static analysis" or
"prepared statements fix everything", but I don't think these are enough.
You only have to skim read things like the second comment (with 27 up votes) on the PDO prepare page
to see that these problems are happening all the time:
http://php.net/manual/en/pdo.prepare.php#111458
SELECT * FROM users WHERE $search=:email
So accept that education alone is not enough, and that the basic building blocks like prepared
statements or ORMs are not enough, and look at these proposals and see how they will make the
language better... because I can assure you, having a simple tainting system that can be switched on
to show your mistakes, is considerably better than what we have today (i.e. nothing... or maybe
using some half baked / expensive static analysis tool).
Or are you scared that this will highlight the mistakes you have made in your own (probably
over-complicated) code? as this is why I want this feature, because I know I have made mistakes, and
with OOP, it is very easy todo so (abstractions like ORMs have a tendency to allow for these
mistakes to creep in extremely easily).
Craig
On 6 Aug 2015, at 23:57, Matt Tait <[email protected]> wrote:
> 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.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>