[whatwg] ContextAgnosticXmlHttpRequest: an informal RFC

Chris Holland frenchy at gmail.com
Tue Mar 8 17:13:00 PST 2005


Thanks for your reply Ian :)

... interesting points: if i understand correctly, such exploit would
require a foreign malicious web page to know the precise URL of an
HTTP/XML service serving sensitive data behind a firewall. Since the
client lives behind the firewall, it'll be able initiate requests to
both foreign and local hosts transparently, resulting in potential
<strike>"undesirable"</strike>dreadful cross-pollination of data into
the foreign document.

Keeping in mind that, in my specification, no cookies or basic auth
credentials would ever be sent as part of a
ContextAgnosticXmlHttpRequest. But it does still open the doors to
unsecured, non-authenticated sensitive data on intranets, and would
put network administrators in the undesirable position where "A
firewall just isn't enough anymore".

eek. yeah. not good. crap. :( i knew i was missing something big! heh
:) ... BUT ...

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.

Could we also further protect this special object by thoroughly:

1) restricting the mime-type it'll accept from the service to text/xml
2) ensuring its validity as a pure parsable XML document

unless both 1) and 2) are met, the object wouldn't expose any readable
properties. i'm trying to ensure that such object would only be able
to read data that is meant to be in some form of syndicated fashion,
and prevent malicious foreign documents to try to load (X)HTML
documents through this object, which would otherwise be served with
text/html mime-types, or, for bolder sites, application/xhtml+xml.

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, 2) opened-up that port on their firewall.

Thanks for the feedback :)

-chris




On Wed, 9 Mar 2005 00:30:19 +0000 (UTC), Ian Hickson <ian at hixie.ch> wrote:
> On Tue, 8 Mar 2005, Chris Holland wrote:
> >
> > http://chrisholland.blogspot.com/2005/03/contextagnosticxmlhttprequest-informal.html
> >
> > I'm basically looking to enable some sort of cross-host *and*
> > cross-domain interoperability between documents via a modified clone of
> > the XmlHttpRequest object, while attempting to tread very carefully on
> > various security issues, such as Cookies and Basic-Auth credentials. A
> > "ContextAgnosticXmlHttpRequest" would be a new object developers could
> > use, beyond the traditional XmlHttpRequest.
> 
> One security problem with the above suggestion is that if you have a
> scenario where host H is accessed by a user U which is behind a corporate
> firewall, and behind that firewall are otherwise unprotected servers
> hosting sensitive information, you just gave hostile host H access to all
> that sensitive data.
> 
> The only real solution I can see is to have the remote server somehow opt
> in to being able to serve pages from any other site. I've been brain-
> storming possible ways to allow this kind of thing in:
> 
>    http://whatwg.org/specs/web-apps/current-work/#network
> 
> ...but nothing currently there should be considered even remotely finished
> yet (or even representative of what I'm currently thinking, it's really
> just a scratchpad).
> 
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
> 


-- 
Chris Holland
http://chrisholland.blogspot.com/



More information about the whatwg mailing list