Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87408
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.169 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: <CAKws9z1939hNu8AnqFd42y_rMB2B_TNDRFVj67dD5go5TmKF4A@mail.gmail.com>
Date: Thu, 30 Jul 2015 16:38:05 +0100
Cc: Matt Tait <matt.tait@gmail.com>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <B8568211-2300-4CA5-B288-EAC52603AB99@craigfrancis.co.uk>
References: <CAEZfaM5t3MpVk=rz7JUPdao=qq96J3cowWQmKboqTgLOXLqaCA@mail.gmail.com> <CAKws9z0k0VDFODWJbsbRGq1WhZy3Bdo3T4pv-MKy+fphkdF=PQ@mail.gmail.com> <542E1FA0-DC44-4DF2-AE25-B03550CBF9A3@craigfrancis.co.uk> <CAKws9z1939hNu8AnqFd42y_rMB2B_TNDRFVj67dD5go5TmKF4A@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 16:24, Scott Arciszewski <scott@paragonie.com> wrote:

>  Just because the solution is known doesn't mean it's known to =
everyone.



Yes, and if you could just read what I was suggesting, rather than =
looking at the subject of this email (and the suggestion by Matt), then =
you will notice this is what I'm trying to do (so not just people asking =
questions on Stack Overflow).

My suggestion is to educate, it also has a nice side effect of having a =
simple checking process for everything else (without breaking anything).









On 30 Jul 2015, at 16:24, Scott Arciszewski <scott@paragonie.com> wrote:

> On Thu, Jul 30, 2015 at 11:20 AM, Craig Francis
> <craig@craigfrancis.co.uk> wrote:
>> On 30 Jul 2015, at 14:43, Scott Arciszewski <scott@paragonie.com> =
wrote:
>>=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.
>>=20
>>=20
>> Good, because my suggestion was also addressing XSS with poor (or =
completely missing) HTML escaping... have a look:
>>=20
>>  http://news.php.net/php.internals/87207
>>=20
>>  https://bugs.php.net/bug.php?id=3D69886
>>=20
>> 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).
>>=20
>> 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.
>>=20
>> Craig
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> On 30 Jul 2015, at 14:43, Scott Arciszewski <scott@paragonie.com> =
wrote:
>>=20
>>> 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
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>=20
>>=20
>=20
> Just because the solution is known doesn't mean it's known to
> everyone. Diffusion of knowledge and good habits is the hardest
> problem in application security to solve. Look, for example, at how
> many college students learn to write C programs with buffer overflow
> vulnerabilities in 2015. We need more effort on education, which is
> part of what I've been focusing on with Paragon Initiative and Stack
> Overflow.
>=20
> Scott Arciszewski
> Chief Development Officer
> Paragon Initiative Enterprises <https://paragonie.com>