Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87431
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=_E0E893D7-0530-44C9-AD81-9144A6CA31D3"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <CAL=_i_k2EAEm7hkNn4MyVrnySpaDLT2HpwfHYp65vo-js84Z5g@mail.gmail.com>
Date: Fri, 31 Jul 2015 11:40:37 +0100
Cc: Scott Arciszewski <scott@paragonie.com>,
 Matt Tait <matt.tait@gmail.com>,
 PHP Internals <internals@lists.php.net>
Message-ID: <5EA0FBC0-75A3-4EF6-9495-DA16021AEF92@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>
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=_E0E893D7-0530-44C9-AD81-9144A6CA31D3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

On 30 Jul 2015, at 17:02, Joe Watkins <pthreads@pthreads.org> wrote:

> 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".



Hi Joe,

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?).

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).

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.

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 :-)

Craig



--------------------------------------------------
http://news.php.net/php.internals/87346
From: Matt Tait
Reply: N/A

Original suggestion.

--------------------------------------------------
http://news.php.net/php.internals/87348
From: Rowan Collins
Reply: Matt Tait

Suggestion to Matt to look for previous RFCs.

--------------------------------------------------
http://news.php.net/php.internals/87350
From: Christoph Becker
Reply: Matt Tait

Points out the existing Taint RFC from 2008, by Wietse Venema.

--------------------------------------------------
http://news.php.net/php.internals/87355
From: Pierre Joye
Reply: Matt Tait

Pointing out that there is more than SQLi (true), and it might be an =
impossible task (I disagree, as explained later).

--------------------------------------------------
http://news.php.net/php.internals/87361
From: Thomas Bley
Reply: Matt Tait

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).

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.

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).

--------------------------------------------------
http://news.php.net/php.internals/87363
From: Lester Caine
Reply: Matt Tait

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).

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).

--------------------------------------------------
http://news.php.net/php.internals/87370
From: Me (Craig Francis)
Reply: Lester Caine

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).

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).

--------------------------------------------------
http://news.php.net/php.internals/87383
From: Lester Caine
Reply: Me (Craig Francis)

Kind of missing the point (maybe my example was too simple), and is =
talking about how Matts solution would cause problems.

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).

--------------------------------------------------
http://news.php.net/php.internals/87386
From: Me (Craig Francis)
Reply: Lester Caine

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?).

--------------------------------------------------
http://news.php.net/php.internals/87391
From: Joe Watkins
Reply: Me (Craig Francis)

Saying you agree with Pierre... I do as well, as Pierre was talking =
about Matt's solution.

--------------------------------------------------
http://news.php.net/php.internals/87393
From: Me (Craig Francis)
Reply: Joe Watkins

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.

--------------------------------------------------
http://news.php.net/php.internals/87396
From: Xinchen Hui
Reply: Joe Watkins

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).

--------------------------------------------------
http://news.php.net/php.internals/87400
From: Scott Arciszewski
Reply: Matt Tait

Pointing out that Cross-Site Scripting is a bigger issue now... where I =
think that taints can address both issues (and more).

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).

--------------------------------------------------
http://news.php.net/php.internals/87403
From: Me (Craig Francis)
Reply: Xinchen Hui

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.

--------------------------------------------------
http://news.php.net/php.internals/87404
From: Me (Craig Francis)
Reply: Scott Arciszewski

Pointing out that I have a different suggestion.

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.

--------------------------------------------------
http://news.php.net/php.internals/87405
From: Scott Arciszewski
Reply: Me (Craig Francis)

Skipping over my suggestion, and just saying that education is needed... =
which is what I'm also trying to do.

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).

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).

--------------------------------------------------
http://news.php.net/php.internals/87406
From: Ronald Chmara
Reply: ???

I'm going to assume this is a reply to Matt's suggestion (or just the =
subject).

And I agree, that suggestion would break every single application... =
hence why I'm not suggesting that approach.

--------------------------------------------------
http://news.php.net/php.internals/87407
From: Me (Craig Francis)
Reply: Ronald Chmara

I'm just explaining that I've hijacked the email thread started by Matt, =
and that there is more to the discussion.

--------------------------------------------------
http://news.php.net/php.internals/87408
From: Me (Craig Francis)
Reply: Scott Arciszewski

I am getting a little frustrated, and just want to move the discussion =
on.

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.

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).

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).

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).

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?).

--------------------------------------------------
http://news.php.net/php.internals/87409
From: Joe Watkins
Reply: Me (Craig Francis)

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).

--------------------------------------------------






On 30 Jul 2015, at 17:02, Joe Watkins <pthreads@pthreads.org> wrote:

> 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


--Apple-Mail=_E0E893D7-0530-44C9-AD81-9144A6CA31D3--