Re: [xml] new PARSER_NO_DISK_ACCESS constant

  yes, and as I said in the bug report, I'm fine working on libxml2 APIs
to make sure we have an as secure as possible framework. Note that we already added a security framework at the libxslt level to check any document loaded
from an XSLT transformation:

I've read the libxml security api page and it seems really extensive. But I'm not asking soo much features :)

So basically you are saying that you would allow it to load DTDs off the network if XML_PARSE_NONET wasn't set, which would still open it up to the same issue. Basically you would want to load the xml (local and remote) without any allowing ANY external entities, which is what I have been looking at. In a case like this my thoughts were as follows (some relate directly to how its implemented in PHP and others are more libxml general): - safe mode, open_basedir and allow_url_fopen settings can be used in PHP
   - Load the xml without validating and without external subsets

So, my question question now is: Is there any security problem with loading external files through the web? I can't see the problem in allowing me to validate xml with an external xml file which is loaded from the internet (and eventually cached in the server - I don't know if libxml can do that, but thats out of the main discussion).

Without having to build a custom external entity loader, which for PHP is being looked at for other reasons and currently using a lower level call ro I/O handling, yet still may have the same issue presented here, I have yet to find a way to prevent the external from being loaded. Once inside the external entity loader, wether default or a custom one, how can it be determined wether this is the initial call (call to load the document) or a subsquential call from parsing the document? I have yet to find any indication from the parser context: both MyDoc and instate are of no help as both empty in both cases (initial load and trying to load the external).

the functions registered as callback in xmlRegisterInputCallbacks() could be extended.. I don't know anything about libxml internals, so I can't really help in deciding where and how to implement those features.

Thanks for your interest,

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]