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

[Kenneth Russell]

On Tue, Oct 4, 2011 at 12:11 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> "default origin behavior" is only relevant when the mode is "No CORS". See
>
http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#potentially-cors-enabled-fetch
>
> So for images it only applies when the "crossorigin" attribute is not set.
>
> So no, WebKit's implementation is not correct if you were trying to
> implement the spec.
>
> In particular, if "crossorigin" is set, you end up at
>
http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#potentially-cors-enabled-fetch
> step 3 item 1 in the 'If mode is "Anonymous" or "Use Credentials"'
section,
> which is exactly what was cited in the mail that started this thread.

Right, I see now. Sorry.

On Tue, Oct 4, 2011 at 12:10 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Tue, 4 Oct 2011, Anne van Kesteren wrote:
> > On Tue, 04 Oct 2011 20:32:02 +0200, Ian Hickson <ian at hixie.ch> wrote:
> > > The idea is that if the server explicitly rejected the CORS request,
> > > then the image should not be usable at all.
> >
> > FWIW, from a CORS-perspective both scenarios are fine. CORS only cares
> > about whether data gets shared in the end. One advantage I can see about
> > <img crossorigin> still displaying the image is that the request does
> > not use cookies. Not displaying the image probably makes debugging
> > easier however.
>
> On Tue, 4 Oct 2011, Boris Zbarsky wrote:
> >
> > Displaying images involves sharing data, basically.  That's why we're
> > having to jump through all these hoops....
>
> On Tue, 4 Oct 2011, Anne van Kesteren wrote:
> >
> > Sure, but not more than per usual. Note that if you do not specify the
> > crossorigin attribute the image can still get untainted. And if it does
> > not you would still display the image (as always).
>
> The thing is that you can grab the image data (at least the alpha channel
> using 2D canvas) from these images, even with tainting enabled, so if the
> server says no, we really should honour it.
>

I don't think that this is a good argument for the currently specified
behavior. The server only has the option of declining cross-origin access if
the application specified the crossorigin attribute. A hostile application
would simply not specify that attribute, would receive the tainted image,
and would use the timing attack I assume you're referring to to infer the
alpha channel.

The far more common case today is that the server doesn't understand the
CORS request, not that it explicitly forbids cross-origin access to the
resource.

It seems to me that tainting the image if the CORS check fails is more
graceful behavior, but I also see the advantages in early error reporting.

Odin, if you file a bug on bugs.webkit.org, would you CC my email address?

-Ken

On Tue, 4 Oct 2011, Boris Zbarsky wrote:
> >
> > And in particular an <img crossorigin> that's in the DOM and fails the
> > CORS checks should not render the image on the page.  Anything else is
> > just broken.
>
> Agreed.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>