XHR: restrictions on request headers

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

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
Accept-Encoding
From
Max-Forwards
Proxy-Authorization

The following seem OK to me:

Cache-Control
Pragma
Warning
Accept
Accept-Charset
Accept-Language
Authorization
If-Match
If-Modified-Since
If-None-Match
If-Range
If-Unmodified-Since
Range
User-Agent
Cookie
Cookie2



Relative to the current spec, this removes restrictions on the  
following:

- Accept-Charset
- Accept-Encoding
- If-Modified-Since
- If-None-Match
- If-Range
- Range

And adds restrictions on the following:

- Date
- Trailer
- Transfer-Encoding
- Upgrade
- Expect
- Referer
- TE


Regards,
Maciej

Received on Tuesday, 11 April 2006 00:04:10 UTC