Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:33330
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain coresecurity.com designates 200.123.107.164 as permitted sender)
Message-ID: <4741F114.5000308@coresecurity.com>
Date: Mon, 19 Nov 2007 17:24:52 -0300
Organization: Core Security Technologies
MIME-Version: 1.0
CC: PHP internals <internals@lists.php.net>
References: <47401946.2050406@sektioneins.de> <fbb0d11d0711181217q4832c62ev7966ac9e98b900b9@mail.gmail.com> <4740B136.2080207@hardened-php.net>
In-Reply-To: <4740B136.2080207@hardened-php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Tainted Mode Decision
From: egutesman@coresecurity.com (Ezequiel Gutesman)

Stefan Esser wrote:
> Hi Dan,
>> I believe the primary use case for taint mode would be to use it in
>> development: taint mode is a mode which can be turned on to give you
>> an idea of where your application may have exposed some
>> vulnerabilities; let you fix those identified vulnerabilities; then
>> turn off for production purposes. The speed of the implementation, if
>> this is indeed the intention for taint mode, would therefore be
>> irrelevant.
> The problem here is that both approaches fail to be completely secure
> even when your test environment
> has 100% code coverage. And I am speaking of real 100% ... Currently
> there is no tool that can
> ensure that. All PHP CC tools I know of so far will for example not
> handle the ternary operator correctly.
> 
> The reason why both taint mode implementations fail are simple. Take the
> following statement.
> 
> $sql['id'] = mysql_real_escape_string($_GET['id']);
> $query = "SELECT * FROM table WHERE id=".$sql['id'];
> 
> Wietse's taint mode will consider this statement safe and never cry.
> GRASP on the other hand will see that there is user supplied data in the
> SQL query, but will ignore it
> because it is a number. It will only react if $sql['id'] contains a
> string. Atleast the very first version did
> this.
> 
> This means currently both approaches would tell the developer that they
> are safe, while they are in fact not.
> 
> Stefan Esser
> 

Hi all, I'm one of CORE GRASP's developers. GRASP was designed to be
used in production stage and hence it is unacceptable to have false
positive and false negative alarms.

As GRASP's objective is to enhance protection in run-time it was only
designed to block on-going attacks and not to warn the developer about
insecure coding habits. We think that Venema's Taint mode is a lot more
helpful in this task.

Going back to Stefan's example:

> $sql['id'] = mysql_real_escape_string($_GET['id']);
> $query = "SELECT * FROM table WHERE id=".$sql['id']

It is true that GRASP won't raise an alarm unless $sql['id'] has
non-numeric characters. This was a design decision since our description
of an attack does not include this example. After analyzing this
example, we cannot see how an attacker could perform a SQL-Injection
attack only with numeric characters; that's why GRASP will not detect
this as an attack.

Ezequiel Gutesman