bugtraq - Re: Firefox focus stealing vulnerability (possibly other browsers)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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/