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

[whatwg] [CORS] WebKit tainting image instead of throwing error

From: Adam Barth <w3c@adambarth.com>
Date: Thu, 6 Oct 2011 08:19:36 -0700
Message-ID: <CAJE5ia-ft5bv49e+dzbXTLhVOeTR5JnYeEoHdOeJeUkOxEacgA@mail.gmail.com>
On Thu, Oct 6, 2011 at 8:16 AM, Anne van Kesteren <annevk at opera.com> wrote:
> On Thu, 06 Oct 2011 17:05:29 +0200, Adam Barth <w3c at adambarth.com> wrote:
>>
>> The reason it's implemented like that is because I didn't add any new
>> security checks. ?I just expanded the canvas taint-checking code to
>> understand that a CORS-approved image could pass.
>>
>> w.r.t. to blocking the whole image, there isn't any security benefit
>> for doing so (if we did so, attackers would just omit the crossorigin
>> attribute). ?If you want to prevent folks from embedding the image,
>> you need something that works regardless of how the image was
>> requested (like From-Origin).
>
> You mean WebKit does not support the crossorigin attribute at all? That is
> how I envisioned CORS to work for <img>.

WebKit does support the crossorigin attribute.  When we issue the
request, if the img has the crossorigin attribute, we add CORS
requests headers.  If an image is ever drawn onto a canvas, then we
check whether it taints the canvas.  If it's an image from another
origin, it taints the canvas unless CORS says otherwise.

Odin is asking why an img with the crossorigin attribute doesn't fail
to load entirely if the server doesn't supply appropriate CORS
headers.

Adam
Received on Thursday, 6 October 2011 08:19:36 UTC

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