W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2006

Re: Extension methods & XMLHttpRequest

From: Jamie Lokier <jamie@shareable.org>
Date: Sat, 10 Jun 2006 23:19:42 +0100
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: Mark Baker <distobj@acm.org>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20060610221942.GA32225@mail.shareable.org>

Lisa Dusseault wrote:
> I wouldn't think that either a whitelist or a blacklist is necessary,  
> but perhaps I haven't thought enough about the problem.  Can somebody  
> provide a list of the methods which would be blacklisted, and why?   
> E.g. can somebody expand on the security problem with CONNECT?
> 	- why is CONNECT always bad, aren't there cases where it's useful
> 	- why that security problem can't be dealt with through other client 
> approaches (e.g.  explaining that the client code for XHR MUST NOT  
> use CONNECT in certain ways)?

Perhaps the main thing is ensuring that proxies and servers can parse
HTTP message boundaries properly, so that requests from different
applications can't interfere with each other.

If request message boundaries are not maintained properly,
XMLHttpRequest can subvert connections from user-agent to an HTTP

That can cause interference between different applications that should
have nothing to do with each other.  They might even be to different
servers, via the same connection to a proxy.  That is a real security hole.

The CONNECT method is special by virtue of having a different
effective syntax than all other methods - the octets sent after the
request are, effectively, part of the request.

No other methods have this property, and none will in future - for
compatibility with existing proxies and servers.  So a blacklist
ruling out CONNECT and no other methods makes sense.

Another way to get a similar effect to CONNECT is using the Upgrade
header, described in RFC2817 and reserved in RFC2616.

Therefore to prevent subversion of HTTP message boundaries,
XMLHttpRequest should prevent:

    - The CONNECT method
    - Setting the Upgrade header

I don't see any reason to disallow any other request methods.

By the way, it would be nice in future to be able to open a
bidirectional unbounded stream sometimes.  I suspect that's what you
had in mind when you said "[CONNECT], aren't there cases where it's
useful".  However, CONNECT with XMLHttpRequest is not usable for that

-- Jamie
Received on Saturday, 10 June 2006 22:20:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:39 UTC