W3C home > Mailing lists > Public > public-webapi@w3.org > May 2008

Re: File IO...

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 7 May 2008 08:47:06 -0700
Cc: "Web API WG (public)" <public-webapi@w3.org>
Message-Id: <C30879D4-EB36-4928-9BD4-CDA653A7B710@apple.com>
To: Charles McCathieNevile <chaals@opera.com>


On May 7, 2008, at 6:39 AM, Charles McCathieNevile wrote:

>
> Hi folks,
>
> Opera has a proposal for a specification that would revive (and  
> supersede)
> the file upload API that has been lingering so long as a work item.
>
> In a nutshell, it provides the ability for a web application to get a
> filespace, by asking the user to identify such a space, and making it
> available to that application something like a virtual file system.

I am concerned about the security implications of this proposal. File  
upload in HTML is based on the user explicitly selecting a particular  
file. This has relatively low security risk, since the user is  
choosing one specific file that he or she wishes to transmit, and all  
that can be done with that file is upload its bytes.

However, this API grants much more power than that. Here are some of  
the more obvious security issues:

1) It allows access to a whole directory at a time. In fact,  
browseForDirectory() starts in the user's home directory by default.  
This makes it very easy to get the unaware user to grant access to  
their whole home directory, or a large part of it. Thus, a user could  
think they are only going to let the web app use a couple of files,  
but in fact it can scan their whole home directory in the background  
for sensitive information.

2) browseForDirectory() can grant access that persists beyond the  
current session. Thus, unlike <input type="file">, which grants one- 
time access, browseForDirectory() grants permanent access to  
everything in a directory for all time. This greatly heightens the  
security risk. Even if I trust a site to read some files once, now if  
it gets hacked and I visit it, it has access to all my files right  
away, without giving me a chance to notice. In addition, users may not  
even be aware that access has been granted permanently, and no  
provision is made for revoking that access.

3) browseForFile() does not have a user interaction restriction or in  
general the good security qualities of <input type="file">.

4) The File object gives many capabilities beyond reading files,  
including copying, moving, and deleting files, and creating files and  
directories. This creates many new security risks. For the first time,  
if the user clicks OK on a dialog, it will be possible for a web  
application to wipe his or her directory. In addition, it will be  
possible to replace applications or other files in the user's home  
directory with malicious native code.

5) The mountpoint: URL protocol is pretty vaguely specified, however,  
if the intent is that this URL scheme is exposed to all web content,  
then as soon as the user has granted one web application access to his  
files, all web sites will have access. If this is not the intent, then  
the new URL scheme has a context-sensitive meaning that is based on  
the refering site, which is complex and is likely to lead to coding  
errors in security policy.

6) Despite clearly having major security considerations, the document  
has no Security Considerations section.


Here are some comments that are not directly security related:

A) The "storage" system directory provides a private filesystem  
sandbox to a web application. Given HTML5 key/value storage and
HTML SQL storage, is it really necessary to have yet another form of  
local data scratch area? Direct file system access, even if sandboxed,  
carries many more risks since for example the UA must be careful to  
avoid following symlinks out of the storage directory and so forth.  
The two HTML5 storage mechanisms avoid this risk. In addition, unlike  
the HTML5 mechanism, no provision is made for quota.

B) The "application" system directory is described as giving access to  
"The files and folders where the application resides". In the case of  
Web applications, the normal place where the application resides is an  
HTTP URL, not a location on the filesystem. The emerging standards- 
based way to locally "install" a web application is HTML5 Application  
caches. This part of the spec seems to presuppose a mechanism to  
locally install a Web application by copying its files to a local  
directory, which is not described in the spec.

C) Instead of building on the successful <input type="file">  
mechanism, which has received close security scrutiny for years, this  
spec builds a whole separate mechanism. No justification is given for  
why a brand new API is better than extending <input type="file">


> Use cases include single or bulk file upload (e.g for images, a set of
> files, etc),

Web Forms 2 already covers this with multi-file upload.


I do not think we can seriously consider this proposal until security  
issues are addressed. The current spec does not seem to have given any  
consideration to Web security.


Regards,
Maciej
Received on Wednesday, 7 May 2008 15:47:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 May 2008 15:47:51 GMT