Last Comment Bug 206859 - can drag text into file upload control
: can drag text into file upload control
Status: VERIFIED FIXED
: csectype-spoof, fixed1.4.3, sec-high
Product: Core
Classification: Components
Component: Security (show other bugs)
: Trunk
: x86 All
: -- major (vote)
: ---
Assigned To: John Keiser (jkeiser)
: Charles Rosendahl
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-05-23 02:46 PDT by Jesse Ruderman
Modified: 2013-06-09 18:49 PDT (History)
9 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Demo: "drag the smiley into the box" (1.46 KB, text/html)
2003-05-23 02:48 PDT, Jesse Ruderman
no flags Details
Don't allow dropping into file inputs. (6.73 KB, patch)
2003-12-19 00:54 PST, Johnny Stenback (:jst, jst@mozilla.com)
caillon: review+
bryner: superreview+
caillon: approval1.4.3+
chofmann: approval1.7a+
Details | Diff | Splinter Review

Description Jesse Ruderman 2003-05-23 02:46:59 PDT
Mozilla allows dragging text into file upload controls.  See the testcase for
how this can be abused.

Suggested fix: allow dragging text into normal text fields but not into file
upload controls.  (This is what IE for Windows does.)

See also:
bug 50660 Should be able to drag FILES to the file upload control
bug 57770 Using styles, clipboard to confuse text entry into file upload control
Comment 1 Jesse Ruderman 2003-05-23 02:48:30 PDT
Created attachment 124058 [details]
Demo: "drag the smiley into the box"
Comment 2 georgi - hopefully not receiving bugspam 2003-05-27 02:33:19 PDT
Probably internet exploder does not allow dragging into upload because IIRC
there was an exploit with only clicking which "emulated" dragging into file upload.
Comment 3 Jesse Ruderman 2003-05-27 04:12:17 PDT
Even if Mozilla doesn't have a bug that can turn a click into a drag, I think
this should be fixed.
Comment 4 Mitchell Stoltz (not reading bugmail) 2003-05-27 13:38:59 PDT
Over to jkeiser. I'd realy like to see this fix get into 1.4.
Comment 5 georgi - hopefully not receiving bugspam 2003-05-28 04:03:45 PDT
I suggest a long term solution to file upload attacks - a warning that a file is
being uploaded (probably also a warning not to turn off the first warning).
This will stop also unknown file upload attacks.
Uploading files does not seem often used, so probably it won't be very annoying.
Comment 6 John Keiser (jkeiser) 2003-05-28 10:10:33 PDT
This seems reasonable.  One can drag into the browse box anyway, and that can't
be obscured.
Comment 7 Mitchell Stoltz (not reading bugmail) 2003-05-28 14:17:30 PDT
John, we think this is dangerous. Can we consider disallowing the dragging?
Comment 8 Samir Gehani 2003-05-30 15:48:03 PDT
adt: nsbeta1-
Comment 9 Asa Dotzler [:asa] 2003-07-27 19:20:07 PDT
mozilla1.4 shipped. unsetting blocking1.4 request.
Comment 10 chris hofmann 2003-08-28 14:36:21 PDT
john, still have cycles to look at this?
Comment 11 chris hofmann 2003-12-18 13:09:34 PST
adding jst to cc list
Comment 12 Johnny Stenback (:jst, jst@mozilla.com) 2003-12-19 00:54:34 PST
Created attachment 137698 [details] [diff] [review]
Don't allow dropping into file inputs.

This fixes this bug, but I'm not sure I got this in the right place. I made the
plain text data transfer code prevent dropping into form controls that don't
allow it, but is that enough? It is for this case, but can others think of
other cases that this might not cover?
Comment 13 Christopher Aillon (sabbatical, not receiving bugmail) 2004-01-04 16:13:44 PST
Comment on attachment 137698 [details] [diff] [review]
Don't allow dropping into file inputs.

I'm wondering if we can avoid getting this far altogether (when we get a drop
event in a form control which doesn't allow dropping, I think we should be able
to avoid even calling the editor methods).    If you want to land this, though,
r=caillon since this route is also fine.  One other thing I'd ask is whether we
want to also consider adding a similar check to nsHTMLDataTransfer.cpp in case
someone wants to disable dropping in their implementation for HTML widgets?
Comment 14 Johnny Stenback (:jst, jst@mozilla.com) 2004-01-14 13:55:15 PST
Comment on attachment 137698 [details] [diff] [review]
Don't allow dropping into file inputs.

I'm kinda leaning towards leaving the code where I originally put it, though
I'm not opposed to finding another place for it, but for now I think I'd prefer
to leave it. And I'm having a hard time imagining a situation where we'd have a
HTML widget form control that doesn't allow dropping into. So I'm going to
leave this as is unless I hear convinsing arguments for moving this check.
Comment 15 Johnny Stenback (:jst, jst@mozilla.com) 2004-02-11 12:44:18 PST
Comment on attachment 137698 [details] [diff] [review]
Don't allow dropping into file inputs.

Duh, forgot to land this last night. It's a security problem, so I'd vote for
taking this for 1.7a.
Comment 16 chris hofmann 2004-02-11 13:05:26 PST
Comment on attachment 137698 [details] [diff] [review]
Don't allow dropping into file inputs.

a=chofmann for 1.7a
Comment 17 Johnny Stenback (:jst, jst@mozilla.com) 2004-02-11 13:32:35 PST
Fixed.
Comment 18 Tracy Walker [:tracy] 2004-05-28 20:34:15 PDT
verified with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b)
Gecko/20040421
Comment 19 Daniel Veditz [:dveditz] 2004-06-17 13:39:25 PDT
Adding Jon Granrose to CC list to help round up QA resources for verification
Comment 20 Christopher Aillon (sabbatical, not receiving bugmail) 2004-07-14 17:08:31 PDT
Comment on attachment 137698 [details] [diff] [review]
Don't allow dropping into file inputs.

a=blizzard for 1.4.3
Comment 21 Christopher Aillon (sabbatical, not receiving bugmail) 2004-07-14 17:19:59 PDT
Fixed on the 1.4 branch
Comment 22 Daniel Veditz [:dveditz] 2004-07-22 02:36:09 PDT
Removing security-sensitive flag for bugs on the known-vulnerabilities list

Note You need to log in before you can comment on or make changes to this bug.