Re: XHR LC comments

* Anne van Kesteren wrote:
>> "For security reasons, these steps should be terminated if the header  
>> argument case-insensitively matches one of the following headers:
>>
>>      * Accept-Charset
>>      * Accept-Encoding
>>      * Connection
>>      * Content-Length
>>      * Content-Transfer-Encoding
>>      * Date
>>      * Expect
>>      * Host
>>      * Keep-Alive
>>      * Referer
>>      * TE
>>      * Trailer
>>      * Transfer-Encoding
>>      * Upgrade
>>      * Via "
>>
>> It's unclear why there's a security reason not to allow things like  
>> "Accept-Charset" or "Accept-Encoding". Please explain.
>
>This was done based on implementation feedback. I haven't investigated  
>what the reasons were for the various headers. If implementors read this  
>maybe they could chime in and point it out.

Note that there are more headers on the list than the ones listed above,
specifically Proxy-*, Sec-*, and it is unclear how to handle, say, the
Cookie and Authorization header.

The correct value, if any, of the Connection, Content-Length, Expect,
Keep-Alive, Trailer, Transfer-Encoding, and Upgrade depends on decisions
about how to transfer the message and how to maintain the connection
that the implementation alone can make, therefore the implementation
rather than the script controls these headers. The Host header is on the
list to ensure scripts cannot bypass same origin restrictions.

Date, Referer, and Via inform about the origin of the request, they are
controlled by the implementation to prevent origin spoofing. The case
for these is much less clear, considering that other headers like User-
Agent are not on the list, and that cross-site requests are not allowed.

Accept-Charset, Accept-Encoding, and TE inform about client capabilities
and it seems the worst that could happen for them is that the server
offers a response the implementation cannot handle, which the server may
do anyway. I don't think their presence is particularily justified. This
is also because some environments treat "X-Y" named headers as if they
were "X_Y" headers and vice versa, if, say, Accept-Encoding is a problem
so would be Accept_Encoding.

Why Content-Transfer-Encoding is on the list I have no idea, HTTP does
not use this header at all, and when I researched this some months ago,
I could not find any particular security problems associated to it, as
far as I remember.

I very much agree the rationale for each header needs to be in the spec,
in a manner that also allows telling why other headers are not.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Wednesday, 14 May 2008 13:34:47 UTC