Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87439
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.172 as permitted sender)
Content-Type: multipart/alternative; boundary="Apple-Mail=_09DEFD70-C0A7-47D0-A5A1-697B4600CAF2"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <CAL=_i_=7SNbWRxFbOSyuAAwt1dppxu+VB3H3Jxo4jfNN0-V1JQ@mail.gmail.com>
Date: Fri, 31 Jul 2015 15:31:18 +0100
Cc: Scott Arciszewski <scott@paragonie.com>,
 Matt Tait <matt.tait@gmail.com>,
 PHP Internals <internals@lists.php.net>
Message-ID: <D76F8AFF-F473-4F44-84DC-1BFEA8B2AF30@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> <B8568211-2300-4CA5-B288-EAC52603AB99@craigfrancis.co.uk> <CAL=_i_k2EAEm7hkNn4MyVrnySpaDLT2HpwfHYp65vo-js84Z5g@mail.gmail.com> <5EA0FBC0-75A3-4EF6-9495-DA16021AEF92@craigfrancis.co.uk> <CAL=_i_=7SNbWRxFbOSyuAAwt1dppxu+VB3H3Jxo4jfNN0-V1JQ@mail.gmail.com>
To: Joe Watkins <pthreads@pthreads.org>
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)

--Apple-Mail=_09DEFD70-C0A7-47D0-A5A1-697B4600CAF2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

On 31 Jul 2015, at 15:00, Joe Watkins <pthreads@pthreads.org> wrote:

> Even the best implementation need only have a single hole in it and =
everything falls apart, one extension not doing something properly, or =
one mistake in the implementation ... it's not hard to imagine these =
things happening, right ?




Hi Joe,

I've just replied to Matt and your email came in as I sent... so a bit =
of a change there.

But what I was proposing was that PHP simply checks the way in which the =
variables (strings) are being passed around... if something from $_GET =
is passed into mysqli_query without being escaped (as a parameter or as =
a quoted escaped string), it will still continue, but a note will be =
written to the log (or on the page if display_errors is on).

The same would happen when you echo a $_GET variable :-)

So in 3015, if the taint checking isn't configured properly (switched =
on)... it wouldn't change the execution, it's just not checking things =
(oh well), it should still have been coded properly to begin with.

So the way in which PHP executes is not effected, it's just picking up =
the "oh, you probably shouldn't be doing this".

Now Matt's suggestion allowed things to be actively blocked... I'm not =
sure I'd use that, but it might work for some (I'd just be happy having =
a log to check, in the same way that I use the logs for undefined =
variables, script timeouts, etc).

And yes, you won't get a perfect system (there are some edge cases)... =
but keeping it as simple as possible (hence why I want to take a =
slightly different approach to the 2008 RFC), it should pick up the most =
common mistakes.

But please do talk about security, you may be wrong, but thats fine, I'm =
sure someone will be able to correct you... I personally feel that too =
many people try to ignore security, and that's why we keep having so =
many problems (that said, performance and accessibility also need some =
attention, but that's more for the developers creating the websites, =
rather than PHP internals).

Craig







On 31 Jul 2015, at 15:00, Joe Watkins <pthreads@pthreads.org> wrote:

> Morning Craig,
>=20
>     I think Pierre and I object to the concept, regardless of the =
intricacies of any particular implementation.=20
>=20
>     Even the best implementation need only have a single hole in it =
and everything falls apart, one extension not doing something properly, =
or one mistake in the implementation ... it's not hard to imagine these =
things happening, right ?
>=20
>     When I made reference to safe_mode, it wasn't because I =
misunderstood the concept, I know you're not introducing another safe =
mode, but introducing a INI, or build, or configuration option that says =
"we got this" is doomed to fail whatever.
>=20
>     I don't like to talk about security, it's not something I feel =
qualified to talk about really, but I can observe that catch-all =
security "features" have already been proven to fail ...=20
>=20
>     It's the year 3015, we're all running PHP442, our taint =
implementation is flawless, every major framework (which we have a =
futurish word for) relies on tainting and thinks SQLi is no longer a =
thing to worry about, because "we got this". A junior sysadmin, on mars, =
is charged with upgrading PHP on the server that is responsible for crop =
irrigation on the terra-formed world, and forgets to configure taint =
properly. The upgrade goes live, renegade ruby fans hack the system =
disrupting food production, leading to the eventual death of everything.
>=20
>    It's Friday afternoon, and that was a bit of fun ... I hope I =
lifted your mood ... push on, I can be wrong, Pierre can be wrong, we =
can all be wrong ...
>=20
> Cheers
> Joe
>=20
> On Fri, Jul 31, 2015 at 11:40 AM, Craig Francis =
<craig@craigfrancis.co.uk> wrote:
> On 30 Jul 2015, at 17:02, Joe Watkins <pthreads@pthreads.org> wrote:
>=20
>> Even if some of those people replying haven't read or don't =
understand what you are suggesting, it is not a good tactic to assume =
that and reply with "read the RFC".
>=20
>=20
>=20
> Hi Joe,
>=20
> Sorry about yesterday, I have done as you have said, and I have read =
those responses again, but unfortunately I still feel that I was right =
in my assumptions (notes below, maybe some interesting additions?).
>=20
> In general I have been getting very frustrated that no-one seems to =
really care about security (and to be fair, it has been annoying me for =
far too many years).
>=20
> Keeping in mind that I work with other developers who routinely keep =
introducing vulnerabilities like SQLi, XSS, CSRF... and doing annoying =
things like switching the CSP off, because they copy/paste some =
hideous/insecure JS, and can't be bothered to work out why the "eval" =
function isn't working.
>=20
> So maybe I should start a new thread, without Matt's subject (btw =
Matt, I really appreciate what you are trying todo, I disagree with the =
blocking element, and I think we can also address more than just SQL =
injection vulnerabilities)... maybe something like "I've found this one =
weird trick that will fix every security issue"... sorry, I hate that =
kind of approach, but if it gets a response, maybe its worth it :-)
>=20
> Craig
>=20
>=20
>=20
> --------------------------------------------------
> http://news.php.net/php.internals/87346
> From: Matt Tait
> Reply: N/A
>=20
> Original suggestion.
>=20
> --------------------------------------------------
> http://news.php.net/php.internals/87348
> From: Rowan Collins
> Reply: Matt Tait
>=20
> Suggestion to Matt to look for previous RFCs.
>=20
> --------------------------------------------------
> http://news.php.net/php.internals/87350
> From: Christoph Becker
> Reply: Matt Tait
>=20
> Points out the existing Taint RFC from 2008, by Wietse Venema.
>=20
> --------------------------------------------------
> http://news.php.net/php.internals/87355
> From: Pierre Joye
> Reply: Matt Tait
>=20
> Pointing out that there is more than SQLi (true), and it might be an =
impossible task (I disagree, as explained later).
>=20
> --------------------------------------------------
> http://news.php.net/php.internals/87361
> From: Thomas Bley
> Reply: Matt Tait
>=20
> Suggesting the use of bound parameters / prepared statements, which I =
agree is how it should be coded by the website developers, but I think =
the PHP language itself can help identify when this has not been done =
(just by raising a notice, not blocking anything).
>=20
> Also Thomas points out that static code analysis could identify these =
issues, but these are far from perfect, and PHP is in a much better =
position to be doing this... and has the advantage of being available to =
everyone.
>=20
> Just to note, I've played with a couple of static code analysers which =
cost in the region of =A319,000 per year, and they still don't find the =
same number of escaping issues that my suggestion can find (they do look =
at other issues, so don't get rid of them, but this one thing that can =
be done better with the programming language itself).
>=20
> --------------------------------------------------
> http://news.php.net/php.internals/87363
> From: Lester Caine
> Reply: Matt Tait
>=20
> Short answer saying you should not use mysql... which I think is a bit =
short sighted (on the assumption that mysqli is a similar interface for =
most website developers).
>=20
> I'm not against using tools like ORMs (e.g. Doctrine), bound =
parameters / prepared statements, or even stored procedures... but they =
all have issues, and are all vulnerable to the kind of misuse I'm trying =
to address (explained in the next email).
>=20
> --------------------------------------------------
> http://news.php.net/php.internals/87370
> From: Me (Craig Francis)
> Reply: Lester Caine
>=20
> Just saying I disagree with Lester, and giving a very simple example =
of how developers can still mess up (once you start adding some =
abstractions, like an ORM, this becomes much harder to detect, and is =
why I'm so insistent that PHP needs to be checking for these issues).
>=20
> This is where I also suggest an alternative to Matt's original =
suggestion (something I posted 12 days before, and didn't really get any =
response).
>=20
> --------------------------------------------------
> http://news.php.net/php.internals/87383
> From: Lester Caine
> Reply: Me (Craig Francis)
>=20
> Kind of missing the point (maybe my example was too simple), and is =
talking about how Matts solution would cause problems.
>=20
> And I agree (sorry Matt), I don't think Matt's solution would work... =
but if Lester had read my reply, he would have seen that my suggestion =
was about education (but it can also help experienced developers as =
well).
>=20
> --------------------------------------------------
> http://news.php.net/php.internals/87386
> From: Me (Craig Francis)
> Reply: Lester Caine
>=20
> Trying to explain to Lester that I agree on education, and pointing =
out that my solution is different... and how (maybe my email was too =
long to read?).
>=20
> --------------------------------------------------
> http://news.php.net/php.internals/87391
> From: Joe Watkins
> Reply: Me (Craig Francis)
>=20
> Saying you agree with Pierre... I do as well, as Pierre was talking =
about Matt's solution.
>=20
> --------------------------------------------------
> http://news.php.net/php.internals/87393
> From: Me (Craig Francis)
> Reply: Joe Watkins
>=20
> Pointing out that my suggestion was different... I realise I'm now =
trying to derail Matt's original thread (this one seems to be getting =
some attention), but I really want to address these same issues.
>=20
> --------------------------------------------------
> http://news.php.net/php.internals/87396
> From: Xinchen Hui
> Reply: Joe Watkins
>=20
> Giving a quick status update on the original 2008 implementation... =
which I personally think is good, but could be made better by switching =
the logic around (I believe this will make the implementation easier, =
and avoid many edge cases).
>=20
> --------------------------------------------------
> http://news.php.net/php.internals/87400
> From: Scott Arciszewski
> Reply: Matt Tait
>=20
> Pointing out that Cross-Site Scripting is a bigger issue now... where =
I think that taints can address both issues (and more).
>=20
> He also says that prepared statements is a solved problem (something =
that I partially disagree with, and have explained above, but I realise =
that Scott is replying to Matt's original email, so may not have read =
that far yet).
>=20
> --------------------------------------------------
> http://news.php.net/php.internals/87403
> From: Me (Craig Francis)
> Reply: Xinchen Hui
>=20
> Just saying that I appreciate the work Xinchen is doing, and offering =
to help (assuming I can)... I do also go off on a bit of a tangent, as I =
think that if we invert the 2008 RFC to mark things when they are =
escaped (rather than tainting everything as they are created), then I =
think the implementation would be a lot easier.
>=20
> --------------------------------------------------
> http://news.php.net/php.internals/87404
> From: Me (Craig Francis)
> Reply: Scott Arciszewski
>=20
> Pointing out that I have a different suggestion.
>=20
> I also wanted to say that I don't think SQL injection is a solved =
problem, as I tried to explain earlier (which Scott may not have read =
yet)... but I certainly didn't want Scott to just sit back and think =
everything is solved now, so no need to discuss.
>=20
> --------------------------------------------------
> http://news.php.net/php.internals/87405
> From: Scott Arciszewski
> Reply: Me (Craig Francis)
>=20
> Skipping over my suggestion, and just saying that education is =
needed... which is what I'm also trying to do.
>=20
> But as PHP is the only thing that can be forced in front of a new =
developer, it is really the only common thing that can do that education =
(there is no way you can find and talk to every single new developer =
just by answering questions on Stack Overflow).
>=20
> And just as an example, college students leaning to write C programs =
in 2015 and creating buffer overflow vulnerabilities... they still make =
mistakes (even highly experienced developers still make these =
mistakes)... and you also have to recognise that not every programmer =
will go to a college, and that not all colleges actually teach their =
students about this (unfortunately).
>=20
> --------------------------------------------------
> http://news.php.net/php.internals/87406
> From: Ronald Chmara
> Reply: ???
>=20
> I'm going to assume this is a reply to Matt's suggestion (or just the =
subject).
>=20
> And I agree, that suggestion would break every single application... =
hence why I'm not suggesting that approach.
>=20
> --------------------------------------------------
> http://news.php.net/php.internals/87407
> From: Me (Craig Francis)
> Reply: Ronald Chmara
>=20
> I'm just explaining that I've hijacked the email thread started by =
Matt, and that there is more to the discussion.
>=20
> --------------------------------------------------
> http://news.php.net/php.internals/87408
> From: Me (Craig Francis)
> Reply: Scott Arciszewski
>=20
> I am getting a little frustrated, and just want to move the discussion =
on.
>=20
> Unfortunately what you don't know is that I've been having this issue =
for too many years, and I'm getting quite annoyed that we aren't =
addressing these problems in a simple way.
>=20
> Instead, what I keep seeing is more complicated half solutions (e.g. =
ORMs and query builders, where typical website developers have no idea =
what the SQL/DB is doing, so vulnerabilities still creep in, and =
introduce other problems like n+1).
>=20
> The amount of times I've been to PHP conferences where the speaker is =
explaining some new way that they are doing OOP (or maybe even =
functional programming), and I'm sure they are really proud of their =
highly complex solution that few people in the audience understand (and =
no, I'm usually able to follow along, my experience is trying to explain =
what the talk was about to another audience member afterwards).
>=20
> But ultimately they haven't addressed anything todo with security, and =
it is often less performant (typical response "hey, get a faster =
computer"), it has instead taken them 3+ months to implement, has =
resulted in another 1 or 2 layers of abstraction that the typical =
developer does not understand (they just run it, and hope for the best).
>=20
> Then in 6 months time they will have moved on to a different complex =
solution, and can't be bothered to support the old one any more (because =
they just want something hard/complex to work on? I'm assuming it's an =
ego thing?).
>=20
> --------------------------------------------------
> http://news.php.net/php.internals/87409
> From: Joe Watkins
> Reply: Me (Craig Francis)
>=20
> Where we are today... where you are talking about the RFC (from 2008, =
or the one from Matt), not what I've just said about my suggestion =
(which, if you haven't read, is different).
>=20
> --------------------------------------------------
>=20
>=20
>=20
>=20
>=20
>=20
> On 30 Jul 2015, at 17:02, Joe Watkins <pthreads@pthreads.org> wrote:
>=20
>> Even if some of those people replying haven't read or don't =
understand what you are suggesting, it is not a good tactic to assume =
that and reply with "read the RFC".
>>=20
>> There is a good chance the majority of the people replying have read =
the RFC, and found reason to be negative, reserved, cautious, or =
whatever.
>>=20
>> The best thing you can do now is read those responses again, and try =
to find what they are saying, if you want the conversation to continue.
>>=20
>> Cheers
>> Joe
>>=20
>> On Thu, Jul 30, 2015 at 4:38 PM, Craig Francis =
<craig@craigfrancis.co.uk> wrote:
>> On 30 Jul 2015, at 16:24, Scott Arciszewski <scott@paragonie.com> =
wrote:
>>=20
>> >  Just because the solution is known doesn't mean it's known to =
everyone.
>>=20
>>=20
>>=20
>> 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).
>>=20
>> My suggestion is to educate, it also has a nice side effect of having =
a simple checking process for everything else (without breaking =
anything).
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> On 30 Jul 2015, at 16:24, Scott Arciszewski <scott@paragonie.com> =
wrote:
>>=20
>> > 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=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,
>> >>>>
>> >>>> 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>
>>=20
>>=20
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>=20
>>=20
>=20
>=20


--Apple-Mail=_09DEFD70-C0A7-47D0-A5A1-697B4600CAF2--