[whatwg] Canvas - toTempURL - A dangerous proposal
Charles Pritchard
chuck at jumis.com
Fri Mar 27 17:22:42 PDT 2009
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
More information about the whatwg
mailing list