Re: XHR: restrictions on request headers

Maciej Stachowiak wrote:
> 
> 
> There's been some discussion of what request headers, if any, 
> XMLHttpRequest should disallow for setREquestHeader.
> 
> I think we really need a clear idea of what we are trying to do by 
> restricting headers. I propose that the following are valid reasons to 
> forbid setting a header:
> 
> 1) It would allow for a possible security hole.
> 2) It would allow a client to cause the UA to violate the http RFC 
> (besides just requirements on syntax, obviously those are possible with 
> any header).
> 3) It could seriously interfere with correct operation of the network 
> layer (specifically, it could break in-progress or future requests, or 
> cause improper responses to be added to the fache.
> 
> I would tentatively say the following are not valid reasons to restrict 
> a header:
> 
> 4) It could result in content that the UA might not be able to parse as 
> text or as XML (this can happen anyway with no custom headers).
> 5) It could result in a response that the UA can't parse at the network 
> level (unless we think this could cause problems so serious that 
> category #3 applies).
> 6) It would not match expectations for information that is commonly 
> present (but in a way that is not a security issue or a violation of the 
> http standard).
> 
> If we agree with this, then I think the standard should list the 3 
> criteria for restricting headers above, and give a justification for any 
> header that is restricted.
> 
> Applying these rules, I think the following http headers should be 
> restricted:
> 
> * Connection (2, 3) - could break other requests on same persistent 
> connection; MUST be 'close' in UAs that don't support persistent 
> connections
> * Date (2) - only allowed to be correct date
> * Keep-Alive (2, 3) - could break requests on same connection or confuse 
> UAs that don't actually support keep-alive
> * Trailer (2) - only allowed with chunked transfer-encoding, some header 
> field names not allowed, must accurately reflect presence of trailer
> * Transfer-Encoding (2, 3) - property of whole message, no way this 
> could properly be set by the XHR client
> * Upgrade (1, 2, 3) - could allow escape to SSL, violating cross-site 
> scripting security rules, could be used to violate RFC by specifying 
> protocol UA does not understand, the latter could actually interfere 
> with correct client operation
> * Expect (2, maybe 3) - client MUST not send an Expect header if it does 
> not intend to send a request body
> * Host (1) - could be used to subvert cross-site sripting rules on 
> servers that use virtual hosting
> * Referer (possibly 1, 2) - the RFC does not appear to allow this to be 
> set to anything but the resource that originated the request (and in 
> some cases requires it to not be sent). Could be a security violation if 
> a site depends on Referer always being either correct or absent.
> * TE (3) - seems like requesting an unknown transfer encoding or 
> trailers for clients that don't understand trailers

We should limit Content-Length too. Apparently some proxies gets 
confused if there are multiple Content-Length headers (i.e. the one that 
XHR produces and the one that's added) and splits a single request into 
two. I believe this would fall under both 1 and 2.

> The following are suspicious. I wasn't able to figure out a specific 
> problem but they seem like they might have the potential for security 
> holes, breaking the protocol, or breaking the client's network stack:
> 
> Via

We restrict Via very likely for good reason. I'll poke the relevant 
people to see why.

/ Jonas

Received on Saturday, 15 April 2006 00:39:42 UTC