Re: CORS Header Filtering?

On Wed, May 12, 2010 at 1:05 PM, Nathan <nathan@webr3.org> wrote:
> Tyler Close wrote:
>>
>> On Wed, May 12, 2010 at 12:33 PM, Nathan <nathan@webr3.org> wrote:
>>>
>>> Yes,
>>>
>>> The simplest argument I can give is that we (server admins) are trusted
>>> to
>>> set the CORS headers, but not to remove any headers we don't want an XHR
>>> request to see - this is frankly ridiculous.
>>
>> The problem is there might not be a single server admin but many.
>> Quoting from the UMP spec:
>>
>> """
>> Some HTTP servers construct an HTTP response in multiple stages. In
>> such a deployment, an earlier stage might produce a uniform response
>> which is augmented with additional response headers by a later stage
>> that does not understand a uniform response header. This later stage
>> might add response headers with the expectation they will be protected
>> by the Same Origin Policy. The developer of the earlier stage might be
>> unable to update the program logic of the later stage. To accommodate
>> this deployment scenario, user-agents can filter out response headers
>> on behalf of the server before exposing a uniform response to the
>> requesting content.
>> """
>>
>> http://dev.w3.org/2006/waf/UMP/#response-header-filtering
>>
>> I believe the design presented in UMP for response header filtering
>> addresses all use-cases, including your "Location" header example
>> below.
>
> Yes that pretty much covers it, can you confirm if "Uniform-Headers" would
> include the Link header as white-listed? That's the last remaining crucial
> one not covered. (Link header is standards track now).

The response would have to also include the header "Uniform-Headers: Link"

> BTW: I will point out that I hadn't reviewed the UMP spec yet so thisn't
> isn't any political or preference thing.
>
> I still stand by my statement though, CORS cannot possible go through to REC
> status without the headers whitelisted in UMP + the Link header.
>
> Although my preference for both specs would be a Blacklist..

We can't know the names of all the possibly dangerous headers. A
dynamic whitelist defined by the server is the best we can do.

--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

Received on Wednesday, 12 May 2010 20:17:29 UTC