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
