[
Lists Home |
Date Index |
Thread Index
]
On Sun, Feb 02, 2003 at 11:42:52AM -0800, Joe English wrote:
>
> Daniel Veillard wrote:
> >
> > Right, I think it's time to bite. If you want high speed parsing
> > don't use entities, okay. This mean don't use entities *in the instances*.
>
> In a Web Service environment, the server has no control
> over whether or not incoming documents use entity references.
> And there's a much bigger issue than performance:
> entity references in the instance require the parser
> to do I/O. That's a security hole waiting to happen,
> no matter how careful you are.
Simply restrict the access to external parsed entities,
seems a very basic control, not a design principle.
> There's a bigger issue than the billion laughs attack.
> Sure, you can limit the recursion depth to prevent this attack,
> and you can run the parser/entity manager in a sandbox to prevent
> access to local files and outgoing network connections, and
That seems very basic
> you can follow xml-dev and the CERT mailing lists to stay
> informed of any new entity-related attacks that someone
> might devise.
The second seems imperative as soon as you run a public service,
i.e. a server with an open port to the internet !!! Nothing will
prevent that cost one way or another.
> Or you could use a parser for an XML subset that doesn't
> support entity references to begin with. That's what I'd do.
Blindly saying "I work on a minimal subset, I don't need to care"
doesn't solve the problem. Like all those users believing in a
magic firewall protecting them so they don't need to care about
security.
> > I seriously think that at least those 2 arguments don't stand in the
> > face of real code engineering, especially if you follow basic good
> > coding practises. It doesn't mean that defining one subset of XML
> > might not be a worthy exercise, but those justifications are IMHO
> > totally impropers to guide this work.
>
> In a Web Service implementation, it's not a matter of
> "if you don't need the feature then don't use it".
> For entity references, it's "don't need them, don't
> want them, must not use them". Good coding practice
> tells me that there are no bugs or security holes in
> code that isn't there, so that's what I'd do.
I can understand that, as long as you can trust the new
subset as much of an existing working superset. And trusting
code need time.
Daniel
--
Daniel Veillard | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
|
