Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87970
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.177 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAEZfaM5t3MpVk=rz7JUPdao=qq96J3cowWQmKboqTgLOXLqaCA@mail.gmail.com>
References: <CAEZfaM5t3MpVk=rz7JUPdao=qq96J3cowWQmKboqTgLOXLqaCA@mail.gmail.com>
Date: Tue, 1 Sep 2015 11:58:08 +0900
Message-ID: <CAGa2bXbVXz2xMi7HKxrnzA=v3VKfwAjnX55zw9vcFObQZO62MQ@mail.gmail.com>
To: Matt Tait <matt.tait@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
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: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi Matt,

My friend made a product called sql_firewall for PostgreSQL.

https://github.com/uptimejp/sql_firewall
http://pgsnaga.blogspot.jp/2015/08/postgresql-sql-firewall.html

It's not directly relevant to your proposal, but this kind of database extension
could be alternative.

PDO has parser for params. Parser may be extended to parse basic SQL syntax
and store syntax tree hash like sql_firewall and compare it to reject
SQL injection
attacks.

Just FYI.

Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net


On Wed, Jul 29, 2015 at 2:33 AM, 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
>
> In short, we make zend_strings track where their value originated. If it
> originated as a T_STRING, from a primitive (like int) promotion, or as a
> concatenation of such strings, it's query that can't have been SQL-injected
> by an attacker controlled string. If we can't prove that the query is safe,
> that means that the query is either certainly vulnerable to a SQL-injection
> vulnerability, or sufficiently complex that it should be parameterized
> just-to-be-sure.
>
> There's also a working proof of concept over here:
>
> http://phpoops.cloudapp.net/oops.php
>
> You'll notice that the page makes a large number of SQL statements, most of
> which are not vulnerable to SQL injection, but one is. The proof of concept
> is smart enough to block that one vulnerable request, and leave all of the
> others unchanged.
>
> In terms of performance, the cost here is negligible. This is just basic
> variable taint analysis under the hood, (not an up-front intraprocedurale
> static analysis or anything complex) so there's basically no slow down.
>
> PHP SQL injections are the #1 way PHP applications get hacked - and all SQL
> injections are the result of a developer either not understanding how to
> prevent SQL injection, or taking a shortcut because it's fewer keystrokes
> to do it a "feels safe" rather than "is safe" way.
>
> What do you all think? There's obviously a bit more work to do; the PoC
> currently only covers mysqli_query, but I thought this stage is an
> interesting point to throw it open to comments before working to complete
> it.
>
> Matt