W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2009

[whatwg] Canvas - toTempURL - A dangerous proposal

From: Charles Pritchard <chuck@jumis.com>
Date: Fri, 27 Mar 2009 17:22:42 -0700
Message-ID: <49CD6DD2.6030105@jumis.com>
Having thought a little more about it (thank you for the feedback),
returning a reference to a custom URL handler (up to the implementation)
would resolve the security issues.

toTempURL returning...  customHandler://randomData.png [any kind of 
reference],
would work in the legacy platforms we're targeting, while allowing us 
the flexibility
of deciding just how to store the data (be it in RAM, or in an unknown 
temporary file).

Amending my proposal:
* toTempURL shall not return a direct reference to the user's hard drive 
(nor temporary files).

The entire implementation of the URL string shall be up to the platform 
designer,
taking necessary security precautions. The output of toTempURL would not
not be guaranteed to be persistent for any length of time, nor have other
access guarantees.



Boris Zbarsky wrote:
> Charles Pritchard wrote:
>> The draw back of this scheme is that Canvas can now write to a users 
>> hard drive.
>> A Denial of Service exploit could run toTempURL in an infinite loop, 
>> filling up
>> the users temporary files directory until the browser puts a stop to 
>> the sillyness.
>
> Even worse, doesn't this allow placement of known bytes in a known 
> location on the user's hard drive without the user's knowledge?  
> That's an excellent first step in an exploit; I would be loath to 
> implement something like that in a browser...
>
> -Boris
Received on Friday, 27 March 2009 17:22:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:47:49 GMT