[whatwg] ContextAgnosticXmlHttpRequest: an informal RFC
ian at hixie.ch
Tue Mar 8 18:06:11 PST 2005
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
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg