Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88217
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain dennis.birkholz.biz does not designate 144.76.185.252 as permitted sender)
To: Craig Francis <craig@craigfrancis.co.uk>,
 Christopher Owen <christopher.owen@live.com>
References: <BLU437-SMTP762BF68D5F013E39BF6AC6E95D0@phx.gbl>
 <CAJW__o3mCdAdm=jaLpLCSpWC4ekmc98CszcUKNr98qu5JgZBeQ@mail.gmail.com>
 <BLU437-SMTP66DB73C07E0C570EC13C4CE95D0@phx.gbl>
 <EBCBA455-F469-4D2A-B21A-B6EA3CE4FAEB@craigfrancis.co.uk>
Cc: Internals <internals@lists.php.net>, wietse@porcupine.org,
 laruence@php.net, Kalle Sommer Nielsen <kalle@php.net>
Message-ID: <55F842FE.6080502@dennis.birkholz.biz>
Date: Tue, 15 Sep 2015 18:10:38 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <EBCBA455-F469-4D2A-B21A-B6EA3CE4FAEB@craigfrancis.co.uk>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] taint
From: php@dennis.birkholz.biz (Dennis Birkholz)

Hi all,

Am 15.09.2015 um 17:09 schrieb Craig Francis:
> 2015-09-14 4:44 GMT+02:00 Christopher Owen <christopher.owen@live.com>:
>> Please consider making ‘taint’ a first-class feature/extension in PHP 7.0.
> 
> I would echo Kalle's suggestion of 7.1.
> 
> But I think you will find it hard to get support... I was pushing this a few weeks ago (either the one from Wietse Venema, the one from Matt Tait, or even my own suggestion), but it seems the developers are more interested in features that make them seem cleaver, rather than pointing out their mistakes...

the problem with taint support is to get it 100% right. If you leave one
edge case open, who is to blame? PHP or the developer that was totally
confident the taint support might warn him?

The short but already stretched example is SQL injection that exploits
character sets (see
http://stackoverflow.com/questions/5741187/sql-injection-that-gets-around-mysql-real-escape-string/12118602#12118602),
slightly adapted:

Your connection is initialized as UTF-8 by default:
$mysqli->set_charset('utf8'); // or $mysqli->query('SET NAMES utf8'),
does not matter

a lot later on, you quote a string you got from the environment:
$str = $mysqli->escape_string($_REQUEST['str']);

and then, you recognize from your session variables the user is Chinese
and you have to switch the database character set so you don't have to
convert is stuff with iconv or something:

$mysqli->set_charset('gbk');
$mysql->query("UPDATE xyz SET foo={$str} WHERE condition");

No problem, right? Taint does not scream, $str is perfectly secure to
use in the query, it was escaped. But it is not. You can argue "use
prepared statements" but that is not always possible. Or "do set your
character set only once directly after you connect". But it is possible,
so users will do it and be surprised if taint does not capture such
problems.

Having different taint classes is not enough, taint needs to hold the
charset the untaint is valid for as well. I am not sure even that get
all edge cases. And if not, it gets really complicated.

Greets
Dennis