- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 9 Mar 2005 02:06:11 +0000 (UTC)
On Tue, 8 Mar 2005, Chris Holland wrote: > > Another feature I had mentioned was for the User Agent to send an HTTP > Refer(r)er header with absolute integrity. The value, in our specific > case, being the URI of our evil foreign document. A publisher of an > HTTP/XML service, to truly secure it and restrict it to local access, > might restrict Referrer values to specific host patterns. Intranet content could just be a Web page, not an HTTP/XML service. There's no way to tell the difference remotely. Existing sensitive content, including existing HTTP/XML services, are not protecting themselves using referrer tracking. Thus, requiring referrer tracking doesn't solve the problem. In any case they couldn't if they wanted to, as the referrer could be anything -- for example, it could be a hotmail.msn.com referrer if an employee is chatting to another employee using his hotmail account and follows a link from such a mail to the other employee's (confidential) documents inside the intranet. > Could we also further protect this special object by thoroughly: > > 1) restricting the mime-type it'll accept from the service to text/xml Web pages, which are part of the content at risk, can be XHTML. One of the correct MIME types for XHTML is text/xml. > 2) ensuring its validity as a pure parsable XML document Not sure what you mean by this. If you mean "The XML document must be well-formed before it can be parsed into a DOM" then that's true already. > Also, and i'm slowly diving further into the crazy-far-fetched here, > should a ContextAgnosticXmlHttpRequest be allowed to only perform > requests on a specific, reserved, TCP port or range of TCP ports? For > intranet sites to be vulnerable, a systems administrator would have had > to 1) made the conscious choice to run their HTTP/XML service on that > specific port, Whatever ports are allowed, port 80 would have to be allowed, otherwise the bar to entry for many authors will be too high. And most of the sensitive content is on port 80. So allowing other ports won't help. > 2) opened-up that port on their firewall. This is all happening on the "safe" side of the firewall, so firewalls won't help here. The only real solution I can see, which I mentioned in the brain storming notes in the draft I cited, is for the UA and third-party host to have a handshake wherein the third-party explicitly states that it accepts to do business with content from the hostile host before any communication is allowed (and if it refuses, the hostile host can't tell the difference between it refusing, and it just being a DNS error, socket closed, or 404 or 500 error -- because knowing which of those it was is a security leak in itself). HTH, -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 8 March 2005 18:06:11 UTC