[whatwg] [CORS] WebKit tainting image instead of throwing error
Adam Barth
w3c at adambarth.com
Thu Oct 6 08:19:36 PDT 2011
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
More information about the whatwg
mailing list