Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87361
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain thomasbley.de from 85.13.137.24 cause and error)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: ALL-INKL Webmail 2.11
In-Reply-To: <CAEZPtU4JECfq8JX0yFZSYPc67LVu_so1_5XE0tYLuh-O97MWnA@mail.gmail.com>
References: <CAEZfaM5t3MpVk=rz7JUPdao=qq96J3cowWQmKboqTgLOXLqaCA@mail.gmail.com> <041328F1-A94D-4B36-BF4F-ED1D9AEB98A9@gmail.com> <55B7E941.3000801@gmx.de><CAEZPtU4JECfq8JX0yFZSYPc67LVu_so1_5XE0tYLuh-O97MWnA@mail.gmail.com>
To: cmbecker69@gmx.de, pierre.php@gmail.com
Cc: rowan.collins@gmail.com, internals@lists.php.net
Message-ID: <20150729012657.ADE1C2606AE@dd15934.kasserver.com>
Date: Wed, 29 Jul 2015 03:26:57 +0200 (CEST)
Subject: Re: [PHP-DEV] [RFC] Block requests to builtin SQL functions where PHP can prove the call is vulnerable to a potential SQL-injection attack
From: mails@thomasbley.de ("Thomas Bley")

Pierre Joye wrote on 28.07.2015 23:05:

> The
> On Jul 28, 2015 11:42 PM, "Christoph Becker" <cmbecker69@gmx.de> wrote:
>>
>> Rowan Collins wrote:
>>
>> > On 28 July 2015 18:33:31 BST, Matt Tait <matt.tait@gmail.com> wrote:
>> >> Hi all,
>> >>
>> >> I've written an RFC (and PoC) about automatic detection and blocking of
>> >> SQL
>> >> injection vulnerabilities directly from inside PHP via automated taint
>> >> analysis.
>> >>
>> >> https://wiki.php.net/rfc/sql_injection_protection
>> >
>> > Have you searched the list archive and wiki for previous discussions
> and prototypes of variable tainting? The idea may well have some legs, but
> there might be some interesting points from previous discussions to note in
> your RFC.
>>
>> FWIW, there is the inactive "Taint support for PHP"[1] RFC.
>>
>> [1] <https://wiki.php.net/rfc/taint>
> 
> Which is what should be done (global tainted mode) and not only for SQL.
> 
> Unfiltered input can affect way more than only SQL. Environment, exec, etc
> are all potentially dangerous with unfiltered data.
> 
> I fear it is an almost impossible task and may give a wrong signal,
> everything is safe of tainted mode is enabled.
> 
> Cheers,
> Pierre
> 


I think it's better to support parameter substitution and escaping directly in the extensions or the core functions:


Idea 1:

mixed mysqli_query_bind ( mysqli $link , string $query [, array $parameters [, int $resultmode = MYSQLI_STORE_RESULT ] ] )

e.g.

mysqli_query_bind($link, 'SELECT * FROM users WHERE usertype = ?', [$usertype]);

mysqli_query_bind($link, 'SELECT * FROM users WHERE id IN (?)', [[1,2,3]]);


Using mysqli_query_bind() means parameters are substituted in as (correctly) escaped strings and the result is run with mysqli_query().


and similar:

exec_bind ( string $command [, array $parameters [, array &$output [, int &$return_var ] ] ] )

echo exec_bind('ls ?', [$someDir]);

Using exec_bind() means parameters are substituted in as (correctly) escaped strings and the result is run with exec().


Those who want to secure their legacy code can use "disable_functions=mysqli_query,exec" and change the occurrences of both functions to the new bind functions.

If people still use echo exec_bind('ls '.$someDir), static code analysis can find it, similar to unsafe includes.

Regards
Thomas