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

From: Date: Thu, 13 Aug 2015 11:00:41 +0000
Subject: Re: [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack
References: 1 2 3 4 5 6 7 8 9 10  Groups: php.internals 
Request: Send a blank email to internals+get-87739@lists.php.net to get a copy of this message
On 12 Aug 2015, at 00:43, Christoph Becker <cmbecker69@gmx.de> wrote:

> On 10.08.2015 at 11:57, Craig Francis wrote:
> 
>> 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
> 
> "Skim reading" things might be the problem (here).  The user contributed
> note states:
> 
> | In my case I allow the user to enter their username or email,
> | determine which they've entered and set $search to "username" or
> | "email". As this value is not entered by the user there is no
> | potential for SQL injection and thus safe to use as I have done.
> 
> So to me that note looks pretty fine.



But that is the problem, many "programmers" (and I know I don't have numbers to back
this up) do just skim read the docs. They often have a problem, and do little research to solve that
immediate problem (i.e. make it run, don't care what it does or how it does it).

I say this as someone who is frequently finding issues that just should not be happening. But at the
moment there is nothing that helps developers identify those problems or mistakes (with the possible
exception of static analysis).

Craig



Thread (45 messages)

« previous php.internals (#87739) next »