Bug 29305 – Canvas drawn with data URL image raises SECURITY_ERR when toDataUrl() called.

• Component: DOM
• Status: RESOLVED FIXED

[Adam Barth]

Importing issue http://code.google.com/p/chromium/issues/detail?id=21847

Reported by [e-mail], Yesterday (36 hours ago)
Chrome Version       : 4.0.206.1 (Official Build 25376)
URLs (if applicable) : http://members.shaw.ca/briantclee/canvas.html
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 4: FAIL. 
  Firefox 3.x: OK
     Opera 10: OK
         IE 7: FAIL. Canvas not supported.
         IE 8: FAIL. Canvas not supported.


What steps will reproduce the problem?
1. Have a webpage:
   1. Create an Image from a data URL.
   2. Create a canvas.
   3. Draw the image to the canvas.
   4. Call canvas.toDataURL().
2. Launch the webpage.


What is the expected result?
toDataURL() returns a data URL for the image drawn to the canvas.

What happens instead?
Error in the console: "Uncaught Error: SECURITY_ERR: DOM Exception 18". 

Drawing from an image with source being a data URL seems to set the
origin-clean flag false. I don't think this should be although it doesn't
explicitly mention this in
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html

[Sam Weinig]

We should make sure to test svg data urls to make sure they don't get through.

[Adam Barth]

(In reply to comment #1)
> We should make sure to test svg data urls to make sure they don't get through.

You mean something like data:text/svg,<svg>...
?

Why shouldn't that get through?

[Oliver Hunt]

(In reply to comment #2)
> (In reply to comment #1)
> > We should make sure to test svg data urls to make sure they don't get through.
> 
> You mean something like data:text/svg,<svg>...
> ?
> 
> Why shouldn't that get through?

The specific issue i think is that you can do

data:application/xml+svg,<svg><image src="evil.com"/></svg>

or whatever.  However i *think* we would catch that as being a multi-origin source.  I think Sam's point was that we need to have a test that ensures the correct restrictions are in place.

[Adam Barth]

This is fallout from our treatment of data URLs being different than required by the HTML5 spec:

===
If a Document or image was generated from a data: URL found in another Document or in a script
The origin is the origin of the Document or script in which the data: URL was found.
===

We'll want to think carefully before adopting this requirement, but I think we can fix the canvas behavior independently.

[Adam Barth]

Created attachment 39820 [details]
Patch v1

[Oliver Hunt]

Comment on attachment 39820 [details]
Patch v1

r=me, we should fix tracking of data url origin as well i guess

[Adam Barth]

Thanks for the review.  I think Maciej has strong opinions about the data URL / noAccess thing.  We'd definitely want to talk with him before changing it.

[Evan Martin]

+        Test that drawing a data URL image onto a canvas behaves as expected.
+        Note the tricky case involving an data URL SVG image with an embedded
+        remote image.

Typo: "an data URL".

[Adam Barth]

> Typo: "an data URL".

Thanks.  I'll fix it on landing.

[Adam Barth]

Committed r48556: <http://trac.webkit.org/changeset/48556>

[Adam Barth]

*** Bug 17150 has been marked as a duplicate of this bug. ***

[Peter van der Zee]

Hi. It seems this problem is back. Tested in nightly WebKit-r52593 on Windows. Given testcase does not show data url. Problem seems to be fixed in nightly Chrome build (r30453) though.

[Adam Barth]

Can you file a new bug and CC the relevant folks?  Odd that the test didn't catch the regression...

[Peter van der Zee]

See Bug 33029