Re: Disabling External Entities in libxml By Default
| From: | Anthony Ferrara | Date: | Thu, 30 Jul 2015 19:32:42 +0000 |
| Subject: | Re: Disabling External Entities in libxml By Default | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-87416@lists.php.net to get a copy of this message | ||
Stas,
On Thu, Jul 30, 2015 at 2:57 PM, Stanislav Malyshev <smalyshev@gmail.com> 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.
Yeah, that seems reasonable. I'll take a peek at the code to see how
bad it will be to separate it (though I'm not familiar with the xml
extensions much).
>> 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.
Yeah, it's a pretty complex problem. I think there should likely be
multiple levels of defense. One level is limiting external entity
requests by default. Another level would be potentially to add a
context option to dom document to allow you to whitelist URLs or
servers.
I think the point would be to document and make it secure by-default,
but provide the ability to turn it back on if you know what you're
doing (though that potentially has a bunch of possible problems as
well).
Anthony