W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: CORS Last Call status/plans? [Was: Re: [UMP] Request for Last Call]

From: Tyler Close <tyler.close@gmail.com>
Date: Mon, 19 Apr 2010 10:06:44 -0700
Message-ID: <u2v5691356f1004191006rc8787b2fse0876f7da1cf6f04@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>, Jonas Sicking <jonas@sicking.cc>
Cc: Julian Reschke <julian.reschke@gmx.de>, Ben Laurie <benl@google.com>, Arthur Barstow <Art.Barstow@nokia.com>, ext Anne van Kesteren <annevk@opera.com>, public-webapps <public-webapps@w3.org>
On Mon, Apr 19, 2010 at 12:41 AM, Maciej Stachowiak <mjs@apple.com> wrote:
> I think a whitelist with opt-in exceptions strikes the right balance between
> security and extensibility. You haven't provided any reasons why that's not
> good enough.

Along those lines, I propose to modify UMP as follows:

"""
4.1 Uniform Response Header

A uniform response is an HTTP response with a single
Access-Control-Allow-Origin header, with the literal string "*" as its
value.

Access-Control-Allow-Origin = "Access-Control-Allow-Origin" ":" "*"

This header MUST only be present if the resource owner permits access
to the response by the content that specified the corresponding
request, regardless of that content's origin.

4.2 Response Header Filtering

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. If the response includes a Uniform-Headers header
with a value "*", no response header filtering is required; otherwise,
the user-agent MUST filter out all response headers other than the
following:

    * Content-Encoding
    * Content-Language
    * Content-Length
    * Content-Location
    * Content-MD5
    * Content-Range
    * Content-Type
    * Expires
    * Last-Modified
    * Location
    * Warning
    * any header whose name is the value of a Uniform-Headers header
on the response

      Uniform-Headers = "Uniform-Headers" ":" ( "*" | #field-name )

The default members of the above whitelist include response entity
headers defined by [HTTP], plus the Location and Warning headers. The
default part of the whitelist does not include: headers used for
credential authentication, such as WWW-Authenticate; nor headers that
might reveal private network configuration information, such as Via;
nor caching headers, such as Age, which provide explicit information
about requests made on behalf of other requesting content.
"""

The header name "Uniform-Headers" is meant to imply that the listed
headers are expected to always accompany the response and so are not
expecting any special security treatment beyond that applied to the
response as a whole.

Are Apple and/or Firefox interested in implementing the above? Does
mnot or other HTTP WG members consider the above a satisfactory
solution to ISSUE-90?

--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html
Received on Monday, 19 April 2010 17:07:17 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:38 GMT