[
Lists Home |
Date Index |
Thread Index
]
Michael Kay wrote,
> A better solution is to nominate an EntityResolver. This will be
> called to check all references to external URIs. If you don't want
> the parser to fetch HTTP URIs, your EntityResolver can prevent it.
> All SAX parsers, I think, have to support this interface.
It's a solution, certainly. But I'm not sure I understand why it's
(always) a better solution. Granted, it's more fine grained, in that it
allows for selective permit/deny/redirect-to-cache/whatever rules for
specific entity URIs. But where that's not needed (ie. we want a
blanket deny-all rule) the SAX feature might be preferable ... ie. less
chances of holes due to coding errors in hand written resolvers.
I'm also not entirely sure it can be completely guaranteed to solve all
the problems. In at least contexts, with at least some implementations
of java.net.InetAddress, the following,
InetAddress.getByName("www.malicious-host.com")
is enough to cause a DNS query to be sent to the nameserver for
www.malicious-host.com. That line of code isn't completely improbable
in a filtering EntityResolver, and the subsequent DNS query might
constitute an unwanted information leak (or worse) even if the entity
isn't actually retrieved.
In any case, the problem is slightly more general than just external
entity references. Any situation where an XML processor, or layers just
above it, but just below the application, automatically (ie. largely
transparently to application developers) attempts a retrieval on an
untrusted URI raises many of the same issues. And that, amongst other
things, covers schemata and RDDL as well as traditional external
entities. In these cases neither a custom EntityResolver nor the SAX
feature will help.
Cheers,
Miles
|
