[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070213122210.GB3904@acs.uni-duesseldorf.de>
Date: Tue, 13 Feb 2007 13:22:10 +0100
From: Andreas Beck <becka-list-bugtraq@...atec.de>
To: bugtraq@...urityfocus.com
Subject: Re: Firefox focus stealing vulnerability (possibly other browsers)
Michal Zalewski <lcamtuf@...ne.ids.pl> wrote:
> > A proper solution would be to keep a list of files explicitly selected
> > by the user and only allow uploads of files in this list. Then even if a
> > script can manipulate the field, the browser won't upload files that
> > have not been selected by the user.
> Not necessarily that easy: notice that it is the user who enters the name
> of a target file.
Right. And in some cases, I find is annoying that you cannot preset paths
for file upload boxes.
I use a web based report generator that can include pictures saved while
investigating the to-be-reported issue and solve it by displaying the
right path above the file path entry box and tell users to copy it to
quickly change to the right directory.
> Unless you want to prevent the browser from accepting any files that were
> not chosen using a visual file selector widget
Not a good idea to limit oneself to visual selectors IMHO. It is sometimes
quite convenient to just paste a known path. Maybe it has also implications
for some handicapped people.
> but in such a case, there's not much point in having a manual file path
> entry box in the first place.
Right. Thus let me suggest a new approach to the problem:
Let scripts and form parser handle upload fields just as usual form
fields. Prefilling them with VALUE, changing them from script, etc. pp.
BUT: Warn the user about uploading files.
Present him with a complete list of all files to be uploaded and a
big warning. And make this dialog not settable to "don't show me again"
and use some kind of "click reflex prevention" like greying out the
"OK" box for the first few seconds.
Yes, this implies the danger, that users will not verify what is to be
uploaded and just click "yes", or will loose track in large uploads
(like photo printing services) or will simply not understand the
implications.
But I think it will be much simpler and secure to implement. All you
need to hook is the form-upload preparation routines. It doesn't matter
with what contrived method a form field has been filled with some
filename - no need to protect it. All that needs protection then is
the dialog that must unambigously state to the user what he is doing.
This would IMHO improve usability for some services (like allowing to
preset the "My Pictures" path for photo print services or the common
path to a logfile for crash-reporting) while dramatically reducing the
amount of code that needs to be watched for interactions with filling
out file upload forms. Without reducing security.
One could even highlight files that are not common to upload (i.e. no
pictures, as this is probably 90% of file upload usage) and remind the
user of the platform-specific dangers of submitting specific files.
Kind regards,
Andreas Beck
--
Andreas Beck
http://www.bedatec.de/
Powered by blists - more mailing lists