W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2011

[whatwg] CORS requests for image and video elements

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 17 May 2011 14:40:14 -0700
Message-ID: <BANLkTimHLNXd1A6QFXEbm_GxQdACW_svbA@mail.gmail.com>
On Tue, May 17, 2011 at 2:25 PM, Kenneth Russell <kbr at google.com> wrote:
> Last week, a proof of concept of a previously theoretical timing
> attack against WebGL was published which allows theft of cross-domain
> images' content.
>
> To address this vulnerability it appears to be necessary to ban the
> use of cross-domain images and videos in WebGL. Unfortunately, doing
> so will prevent entire classes of applications from being written, and
> break a not insignificant percentage of current applications.
>
> We would like to use CORS to solve this problem; if the server grants
> access to the image or video, WebGL can use it. Initial discussions
> with image hosting services have been positive, and it seems that CORS
> support could be enabled fairly quickly. Many such services already
> support other access control mechanisms such as Flash's
> crossdomain.xml. Unfortunately, experimentation indicates that it is
> not possible to simply send CORS' Origin header with every HTTP GET
> request for images; some servers do not behave properly when this is
> done.
>
> We would like to propose adding a new Boolean property, useCORS, to
> HTMLImageElement and HTMLMediaElement, defaulting to false. If set to
> true, then HTTP requests sent for these elements will set the Origin
> header from the page's URL. If the Access-Control-Allow-Origin header
> in the response grants access, then the content's origin will be
> treated as the same as the page's.
>
> Perhaps an API could also be added to find out whether the server
> granted CORS access to the resulting media, though this is less
> important. (Note that the canvas element does not have an explicit API
> for querying the origin-clean flag.)
>
> Thoughts on this proposal? We would like to decide on a path quickly
> so that we can update both specs and implementations.

I like the general idea, though i'm not too excited about the name
"useCORS". But lets leave that bikeshedding for a more boring day :)

There is however one more decision that needs to be done. Does setting
"useCORS" make the CORS implementation execute with the "supports
credentials" flag set to true or false?

When set to true, the request to the server will contain the normal
cookies which the user has set for that domain. However, the response
from the server will have to contain "Access-Control-Allow-Origin:
<origin>". In particular "Access-Control-Allow-Origin:*" will not be
treated as a valid response.

If the "supports credentials" flag is set to false, the request will
be made without cookies, and the server may respond with either
"Access-Control-Allow-Origin:*" or "Access-Control-Allow-Origin:
<origin>".

I propose that the latter mode is used as it will make servers easier
to configure as they can just add a static header to all their
responses.

/ Jonas
Received on Tuesday, 17 May 2011 14:40:14 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:33 UTC