[whatwg] ContextAgnosticXmlHttpRequest: an informal RFC

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'