W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > November 2012

[Bug 20034] canvas getImageData opens security whole for code

From: <bugzilla@jessica.w3.org>
Date: Thu, 22 Nov 2012 04:35:02 +0000
To: public-html-bugzilla@w3.org
Message-ID: <bug-20034-2486-EUNDQi9VEe@http.www.w3.org/Bugs/Public/>

rcabanie <cabanier@adobe.com> changed:

           What    |Removed                     |Added
                 CC|                            |cabanier@adobe.com
           Assignee|jaymunro@microsoft.com      |cabanier@adobe.com

--- Comment #8 from rcabanie <cabanier@adobe.com> ---
(In reply to comment #7)
> > When you has normal XHR code there is per default an validation of the same
> > host.
> Yes, but hosts can opt in to loads from them.
> And while browsers can load images from anywhere, and draw them into a
> canvas, they can only getImageData the result if the image was from the same
> host or if the host opted into it, just like XHR.
> > Also any Virus detection tools can block it when they found a signature of
> > malicious text (code).
> Again, if the web page is not cooperating, right?  If the web page and the
> server are cooperating, then they can just obfuscate the source code (rot13,
> encrypt, encode as an image, whatever).
> It really would help if you answered my questions about your attack model...
> because as far as I can tell, getImageData doesn't allow anything
> XMLHttpRequest didn't already allow.

I agree.
A script has multiple other ways to obfuscate malicious code.
This is an interesting way of new way of transmitting JS code, but it doesn't
open up a new attack vector since it's easy to encrypt JS.

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Thursday, 22 November 2012 04:35:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:35 UTC