toDataUrl. Therefore, cross-domain checks are required on the usage of these APIs. In Firefox, these checks were present but did not cater for the "302 redirect trick" properly.
So what is the "302 redirect trick"? It is where a malicious web page accesses a remote resource by referring to a local same-domain URL which hits the remote resource via an HTTP redirect. If the attacker is lucky, the browser is fooled into believing the remote resource is actually a local resource. And then theft is trivial.
The "302 redirect trick" has appeared many times in the past. It will undoubtedly lead to more vulnerabilities (I have two pending in fact). My personal past favourite was from my Google colleague Martin Straka, who noticed that 302 redirect targets leaked into the DOM when loading stylesheets.
The "302 redirect trick" works particularly well in cross-domain areas where the cross-domain nature of requests used to be unimportant. In this example of images, it has always been accepted that existence (or not) and width / height leaks cross-domain. However, getting the domain right became critical when the image data itself became accessible. Contract with iframes, where getting the domain right has always been critical. Browsers tend to not suffer vulnerabilities when loading iframes via a redirect.
Full details including demo attack code are in the advisory: