Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87405
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain paragonie.com from 209.85.220.182 cause and error)
MIME-Version: 1.0
In-Reply-To: <542E1FA0-DC44-4DF2-AE25-B03550CBF9A3@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>
Date: Thu, 30 Jul 2015 11:24:19 -0400
Message-ID: <CAKws9z1939hNu8AnqFd42y_rMB2B_TNDRFVj67dD5go5TmKF4A@mail.gmail.com>
To: Craig Francis <craig@craigfrancis.co.uk>
Cc: Matt Tait <matt.tait@gmail.com>, PHP Internals <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: scott@paragonie.com (Scott Arciszewski)

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:
>
>> 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=69886
>
> 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,
>>>
>>> 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
>>
>> Hi Matt,
>>
>>> 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.
>>
>> 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.
>>
>> 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")
>>
>> Scott Arciszewski
>> Chief Development Officer
>> Paragon Initiative Enterprises <https://paragonie.com>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>

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.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>