Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87418
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain cdatazone.org does not designate 216.22.18.221 as permitted sender)
To: Stanislav Malyshev <smalyshev@gmail.com>,
 Anthony Ferrara <ircmaxell@gmail.com>, Jake <php@freepanel.net>
References: <CAAyV7nES6A+_68A2eMdxAGw--_R-A7WhhQJ6VyMzi5p7PneBXw@mail.gmail.com>
 <55BA59A1.9020503@freepanel.net>
 <CAAyV7nHKseQ1hX0XhN6WDvfJR+A10HX=apcK=hMXTSijQucbMA@mail.gmail.com>
 <55BA7395.2090202@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Message-ID: <55BA8F2A.4030202@cdatazone.org>
Date: Thu, 30 Jul 2015 16:55:06 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0)
 Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <55BA7395.2090202@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Disabling External Entities in libxml By Default
From: rrichards@cdatazone.org (Rob Richards)

On 7/30/15 2:57 PM, Stanislav Malyshev wrote:
> Hi!
>
>> The problem here is that imagine the following:
> I think if we separate the loading the initial file (i.e., staring point
> of the XML parser) and the loading the entities from that file (which is
> not happening right now) we'd solve many BC problems. Not sure about
> SOAP, but many others for sure.

It will solve many but your guess is as good as mine as to what the 
split will be. All come down to what people are doing with XML. I've had 
comments from both sides where people hate the way its currently 
implemented and have suggested the idea of allowing initial file and 
then from others who like it as is. Regardless tho the current 
implementation should definitely not be enabled by default but I could 
see something laxer like this. I still say it should be a different 
function and leave the current one as is.

>
>> I know that you want it to work, but this is actually a great place to
>> fail, because you're loading a trusted resource over HTTP. Meaning
>> that an attacker could MITM and inject malicous XML into the response,
>> and own your server without even needing to own the endpoint.
> I feel like XML parser is a wrong place to solve this problem, transport
> security can be done in HTTPS, signatures, etc. Otherwise many protocols
> that rely on XML - such as SAML, which is quite widely used - would be
> completely useless.
>

Rob