document.implementation.createDocument vulnerability - reading arbitrary XML files using HTTP redirects This page reads xml2.xml and shows the first tag name but easily may be modified to enumarate the whole DOM. The code is: --------------------------------- <SCRIPT> d=document.implementation.createDocument("","",null); d.load("http://ORIGINATINGHOST/SOMETHINGTTHATREDIRECTSTO_XML2.XML","text/xml"); setTimeout("alert('tagname='+d.documentElement.tagName);",2000); //setTimeout("alert(d.firstChild);",2000); </SCRIPT> --------------------------------- document.implementation.createDocument vulnerability - reading arbitrary XML files using HTTP redirects This page reads xml2.xml and shows the first tag name but easily may be modified to enumarate the whole DOM. Written by Georgi Guninski <test> xml </test>
document.implementation needs a thorough security review.
Status: NEW → ASSIGNED
Mass changing QA to ckritzer.
QA Contact: junruh → ckritzer
All right, finally able to reproduce this. Adding URL for testcase above. Sorry it's NS-internal, I needed a server that could be reconfigured for a redirect. Basically, this does document.load("http://grey/u/mstoltz/bugs/redirect_to_xmlbase.xml"); and the URL in the above call is redirected to "http://grey.mcom.com/u/mstoltz/bugs/xmlbase.xml". Note that the redirected URL is grey.mcom.com, so Mozilla should treat this as a different host than "grey." If we loaded an xml document directly from grey.mcom.com, we would not be able to read its DOM, since it's coming from a different hostname. However, when we redirect from grey to grey.mcom.com, the principal remains "grey" when it should be changed to "grey.mcom.com." Obviously, the principal needs to be updated when the redirect occurs, this happens during a normal document load but not in this case for some reason.
The reason we don't see the redirect in this case is that we're at a lower level when we do a document.load() so the code that normally deals with the redir stuff is not used. I poked around a bit and I came up with a fix for this, the fix makes the nsXMLDocument an nsIHTTPEventSink and the document is set to get the callback notifications from necko and once OnRedirect is called I modify the principal and the testcase fails to access the DOM of the XML document. I'll attach the patch, pelase have a look and let me know what you think about the general idea.
This patch seems to work fine. The script is no longer able to read the redirected page, unless the script is run from the same host as the redirected page. I tried the same testcase without the redirect, and it still enforces same-origin correctly. r=mstoltz
sr=vidur. The GetInterface() could just unconditionally call QueryInterface() since the class implements nsIHTTPEventSink. Not a big deal, though.
Fix (including the GetInterface() optimization) checked in. Marking FIXED.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Sooo...based on mstolz's comments (and my understanding of same origin) because I get dumped to http://search.netscape.com/cgi-bin/search?charset=UTF-8&search=grey , this is a good thing because it didn't load the redirect. Am I correct in my thinking or am I suffering from UserHeadGap?
Whiteboard: need engineer feedback
whoops, sorry. No, you got bumped into Netcenter Search because grey is temporarily offline. It'll be back up sometime this afternoon. The exploit reads from an XML file that it shouldn't be able to read from and displays some stolen info in an alert. With the fix, the alert should not show up, and you should (I think) see a security excption thrown to the JS console. The redirect and the 'stolen' document never actually appear on the screen.
Okay, when I load http://grey/u/mstoltz/bugs/57466.html, I get a page which looks like this: <h1>57466</h1> ... <hr> <a href="mailto:firstname.lastname@example.org">Mitchell Stoltz</a> Last modified: Wed Nov 29 15:40:55 PST 2000 And nothing else happens. After looking over the source, and carefully re-reading the bug, it appears that there may be another bug blocking this one. It seems that the 57466.html file should be creating a new document and then loading an existing xml webpage, but is throwing an NS_ERROR_DOM_PROP_ACCES_DENIED exception. Mitch, is this the current expected behaviour?
You got it, Chris. If you get the access denied error and you don't see an alert which gives you some of the contents of the XML file, then we're golden.
Beauty. I guess we're golden then <grin> Marking Verified FIXED on: MacOS90 2001-02-13-04-Mtrunk LinRH62 2001-02-13-06-Mtrunk MOZILLA Win98SE 2001-02-13-06-Mtrunk
Status: RESOLVED → VERIFIED
Removing NS_Confidential flag.
You need to log in before you can comment on or make changes to this bug.