[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XInclude: security risk 1

• To: xml-dev@l...
• Subject: Re: XInclude: security risk 1
• From: Richard Tobin <richard@c...>
• Date: Sun, 27 Oct 2002 00:13:26 +0100 (BST)
• Cc:
• In-reply-to: <p04330100b9e080b82819@[192.168.254.4]>
• Organization: HCRC, University of Edinburgh

>How bad is this? Does this do anything a hacker can't do with IMG 
>tags or external entity references now? I do think this is worse than 
>those cases because fallbacks let the result of the load be 
>communicated back to the original host (or a different one).

That's an interesting point.  You may be able to obtain some feedback
with entity references too, since if the entity reference fails in
some way then the rest of the document may not be processed, including
later entity references.  But the XInclude case may be more useful,
depending on exactly what circumstances the processor falls back or
aborts.

>Combined with JavaScript and DHTML, this attack could become a lot 
>more effective. If the browser exposes the post-include DOM to any 
>such technology, then this would allow the remote site to gather 
>information from normally restricted pages on the Intranet.

This on the other hand seems to be exactly the same as the entity
reference case: my Javascript looking at a DOM with your file:///whatever
XIncluded is no worse than looking at a DOM with your file:///whatever
entity expanded.

Maintainers of web-based validators should worry about the same
problem.

-- Richard

• References:
  • XInclude: security risk 1
    • From: Elliotte Rusty Harold <elharo@m...>

• Prev by Date: Re: [ANN] "Future of Software and Databases" NetSeminar (December 3)
• Next by Date: Re: ANN: xpath1() scheme for XPointer
• Previous by thread: Re: XInclude: security risk 1
• Next by thread: Re: XInclude: security risk 1
• Index(es):
  • Date
  • Thread