On Tue, Oct 4, 2011 at 11:32 AM, Odin Hørthe Omdal <odi...@opera.com> wrote: > If the CORS-check did not succeed on <img > src=http://crossorigin.example.net crossorigin>, this should happen > according to spec: > >> Discard all fetched data and prevent any tasks from the fetch algorithm >> from being queued. For the purposes of the calling algorithm, the user agent >> must act as if there was a fatal network error and no resource was obtained. >> If a CORS resource sharing check failed, the user agent may report a >> cross-origin resource access failure to the user (e.g. in a debugging >> console). > > <http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#potentially-cors-enabled-fetch> > > > In this scenario an author wanting to do some canvas processing with the > image, will be able to check img.onerror to see whether she can use that > image. The image won't load on a failed check. Gecko does this. > > WebKit, on the other hand, only taints the image and loads it anyway, > breaking the spec. The error will instead crop up in a way that is more > verbose and harder to miss when she tries to read the image data out. > > Is WebKit's method a lesser surprise than the image just not showing up > (if they don't check for thrown error)? It'd be nice to hear why it's > implemented like that, if there are any good reasons. WebKit's method > seemed most obvious to me at first, but after investigating a bit I'm not > sure anymore...
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). Adam
