Re: File IO...

On May 7, 2008, at 9:47 AM, Maciej Stachowiak wrote:

>
>
> 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.
>

This is possible today on IE and Mozilla with a single user-visible  
security prompt. Once answered this functionality is accessible.

> 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.

"Remember this decision" to the above prompt.

>
>
> 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.
>

Again, these risks exist today in IE and Mozilla. Coming up with a  
standardized, sandboxed alternative would be perhaps far better than  
continuing along with our heads in the sand.

> 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.
>

Clearly if all i want is scratch area I don't need file system access.  
But there are use cases for integrating a browser-based application  
with the host operating system that can't be addressed in that  
fashion. It's naive to imagine that these use cases won't continue to  
create pressure to expand the capability of the browser as a "VM"  
until it is on a par with, say, the JVM, in terms of what it can do  
when properly authenticated. The ease of authoring and deployment to a  
browser means the VM of choice these days is a browser and that VM  
will be forced to grow powerful enough to support all functionality  
required by modern applications.

> 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 18:23:46 UTC