OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Elliotte Rusty Harold on Web Services

[ 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

> >   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 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/


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS