Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87404
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain craigfrancis.co.uk designates 209.85.212.175 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <CAKws9z0k0VDFODWJbsbRGq1WhZy3Bdo3T4pv-MKy+fphkdF=PQ@mail.gmail.com>
Date: Thu, 30 Jul 2015 16:20:28 +0100
Cc: Matt Tait <matt.tait@gmail.com>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <542E1FA0-DC44-4DF2-AE25-B03550CBF9A3@craigfrancis.co.uk>
References: <CAEZfaM5t3MpVk=rz7JUPdao=qq96J3cowWQmKboqTgLOXLqaCA@mail.gmail.com> <CAKws9z0k0VDFODWJbsbRGq1WhZy3Bdo3T4pv-MKy+fphkdF=PQ@mail.gmail.com>
To: Scott Arciszewski <scott@paragonie.com>
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: craig@craigfrancis.co.uk (Craig Francis)

On 30 Jul 2015, at 14:43, Scott Arciszewski <scott@paragonie.com> wrote:

> This may have been true at one point in time, but my own experience
> and the statistics collected by Dan Kaminsky of White Hat Security
> indicates that Cross-Site Scripting vulnerabilities are much more
> prevalent in 2015 than SQL Injection, especially in business
> applications.


Good, because my suggestion was also addressing XSS with poor (or =
completely missing) HTML escaping... have a look:

  http://news.php.net/php.internals/87207

  https://bugs.php.net/bug.php?id=3D69886

Now I admit it won't fix everything with XSS (as HTML escaping is a bit =
harder), but it certainly will pick up quite a lot of the issues (and it =
wont break anything either, just help developers identify problems).

And no, SQL injection is far from a solved problem... this is why, after =
15 years of me trying to tell my fellow developers to not make these =
mistakes, I'm still finding them making them over and over again... =
hence why I'm making the above suggestion.

Craig






On 30 Jul 2015, at 14:43, Scott Arciszewski <scott@paragonie.com> wrote:

> On Tue, Jul 28, 2015 at 1:33 PM, Matt Tait <matt.tait@gmail.com> =
wrote:
>> Hi all,
>>=20
>> I've written an RFC (and PoC) about automatic detection and blocking =
of SQL
>> injection vulnerabilities directly from inside PHP via automated =
taint
>> analysis.
>>=20
>> https://wiki.php.net/rfc/sql_injection_protection
>>=20
>> 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.
>>=20
>> There's also a working proof of concept over here:
>>=20
>> http://phpoops.cloudapp.net/oops.php
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> Matt
>=20
> Hi Matt,
>=20
>> 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.
>=20
> This may have been true at one point in time, but my own experience
> and the statistics collected by Dan Kaminsky of White Hat Security
> indicates that Cross-Site Scripting vulnerabilities are much more
> prevalent in 2015 than SQL Injection, especially in business
> applications. If Google has information that indicates that SQLi is
> still more prevalent than XSS, I'd love to see this data.
>=20
> In my opinion, SQL injection is almost a solved problem. Use prepared
> statements where you can, and strictly whitelist where you cannot
> (i.e. "ORDER BY {$column} ASC")
>=20
> Scott Arciszewski
> Chief Development Officer
> Paragon Initiative Enterprises <https://paragonie.com>
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20