Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87402
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.170 as permitted sender)
To: internals@lists.php.net
References: <CAAyV7nES6A+_68A2eMdxAGw--_R-A7WhhQJ6VyMzi5p7PneBXw@mail.gmail.com>
 <55B94D57.4070509@gmail.com> <55BA22C5.2020104@cdatazone.org>
Message-ID: <55BA34EF.6030209@gmail.com>
Date: Thu, 30 Jul 2015 15:30:07 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <55BA22C5.2020104@cdatazone.org>
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: rowan.collins@gmail.com (Rowan Collins)

Rob Richards wrote on 30/07/2015 14:12:
> If you are already working with a trusted document then you should 
> safely be able to disable the entity loader. If you aren't then 
> wouldn't you want to do some sort of checking (especially if you dont 
> have an XML gateway fronting the system) for other malicious things 
> before even opening the document regardless if it has external 
> entities or not.

Can you give any pointers to what kind of checking this would be, and 
how it would be carried out without parsing the XML document in the 
first place?

According to the bug report, one of the affected uses is the SoapClient, 
which by definition is dealing with remote data. I can see how that 
could be considered "untrusted", but I can't think of any particular 
action that would make it more trusted (quite apart from the lack of an 
obvious point to intercept the data before it is parsed).

Would it not make more sense for the parser to operate in an "untrusted" 
mode - disabling external entities, maybe different limits on stack 
depth, etc?

Regards,
-- 
Rowan Collins
[IMSoP]