Re: Cross-site Requests and Custom HTTP Headers

Jonas:

You are correct. The list I posted contained at two HTTP Headers that
do not apply to "safe" HTTP methods (GET/HEAD). I should never have
included:
If-Match
If-Unmodified-Since

Also, it was not clear to me when reading Anne's proposal on WL/BL
that the lists are only applied during the "send" phase of an HTTP
Request. Therefore, I should not have included the HTTP Headers that
are sent by the Server in *response* to GET/HEAD requests. I noticed
that the "Expect" header appears on the XMLHttpRequest list of
restricted headers and I missed that, too.

That leaves me with the following HTTP Headers that I propose for
inclusion in the whitelist:
1. Accept
2. Accept-Language
3. Accept-Ranges
4. Cache-Control
5. If-Modified-Since
6. If-None-Match
7. If-Range
8. Max-Forwards ??
9. Pragma
10. Range
11. User-Agent ??

I propose 4,5,6 and 9 since they are used in caching and can reduce
traffic. The best threat I could come up with would be malformed
versions of these headers that would result in the server returning a
fresh copy each time.

I propose 1,2,3,7 and 10 since they are used by clients to inform the
server of the mime-types, languages, and byte-ranges for the requested
resource. Items 1 and 2 have already been discussed. While it is
possible to craft a request that contains invalid byte ranges using
items 3,7 and 10, it is up to the server that is accepting and acting
on these headers to handle malformed cases.

This leaves 8 and 11. The "Max-Forwards" header is mostly a debugging
header and not often used. I can't make a compelling case for it, but
am not volunteering to blacklist it at this point. The ability to
craft a custom "User-Agent" can also come in handy, but might be a
'spoofing' problem. I am ambivalent about these two.

Blacklist "From" Header
I removed the "From" header from my initial list and propose it be
added to the blacklist instead. While not often used, it is defined
for passing the user's email address.

Handling Questionable Response Headers
Finally, I note that Anne's proposal at the top of this thread states:
"BL is the list of headers currently listed in the XMLHttpRequest
specification under the setRequestHeader() algorithm  with the
addition of cookie and credentials headers."

Is it then correct to assume that the following headers (when sent by
the server in response to a GET/HEAD) will result in a SECURITY_ERR?

WWW-Authenticate
Authentication-Info
Set-Cookie

MikeA




On Tue, Feb 26, 2008 at 6:54 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>
> mike amundsen wrote:
>  > I propose the following HTTP Headers be added to the white list:
>  >
>  > Accept
>  > Accept-Language
>  > Accept-Ranges
>  > Age
>  > Allow
>  > Cache-Control
>  > Content-Disposition
>  > Content-Language
>  > Content-Location
>  > Content-MD5
>  > Content-Range
>  > Content-Type
>  > ETag
>  > Expect
>  > Expires
>  > From
>  > If-Match
>  > If-Modified-Since
>  > If-None-Match
>  > If-Range
>  > If-Unmodified-Since
>  > Last-Modified
>  > Location
>  > Max-Forwards
>  > Pragma
>  > Range
>  > Refresh
>  > Retry-After
>  > Server
>  > Transfer-Encoding
>  > User-Agent
>  > Vary
>  > Warning
>
>  So first off this whitelist only matters for GET requests. So headers
>  that doesn't make sense for GET I don't see a reason to allow, that
>  especially includes request headers.
>
>  I'm wondering what you based this list on, and why you think that these
>  headers are all going to be safe? For example Content-MD5 (apart from
>  the fact that it doesn't make sense for GET requests) seems dangerous if
>  the server relies on it being truthful.
>
>  / Jonas
>
>  / Jonas
>



-- 
mca
http://amundsen.com/blog/

Received on Wednesday, 27 February 2008 02:13:49 UTC