Closed
Bug 206859
Opened 22 years ago
Closed 21 years ago
can drag text into file upload control
Categories
(Core :: Security, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: jruderman, Assigned: john)
References
Details
(Keywords: csectype-spoof, fixed1.4.3, sec-high)
Attachments
(2 files)
1.46 KB,
text/html
|
Details | |
6.73 KB,
patch
|
caillon
:
review+
bryner
:
superreview+
caillon
:
approval1.4.3+
chofmann
:
approval1.7a+
|
Details | Diff | Splinter Review |
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
Reporter | ||
Comment 1•22 years ago
|
||
Reporter | ||
Updated•22 years ago
|
Flags: blocking1.4?
Comment 2•22 years ago
|
||
Probably internet exploder does not allow dragging into upload because IIRC
there was an exploit with only clicking which "emulated" dragging into file upload.
Reporter | ||
Comment 3•22 years ago
|
||
Even if Mozilla doesn't have a bug that can turn a click into a drag, I think
this should be fixed.
Comment 4•22 years ago
|
||
Over to jkeiser. I'd realy like to see this fix get into 1.4.
Assignee: mstoltz → jkeiser
Keywords: nsbeta1
Comment 5•22 years ago
|
||
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.
Assignee | ||
Comment 6•22 years ago
|
||
This seems reasonable. One can drag into the browse box anyway, and that can't
be obscured.
Status: NEW → ASSIGNED
Comment 7•22 years ago
|
||
John, we think this is dangerous. Can we consider disallowing the dragging?
Comment 10•22 years ago
|
||
john, still have cycles to look at this?
Comment 11•21 years ago
|
||
adding jst to cc list
Comment 12•21 years ago
|
||
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?
Updated•21 years ago
|
Attachment #137698 -
Flags: superreview?(hjtoi-bugzilla)
Attachment #137698 -
Flags: review?(caillon)
Reporter | ||
Updated•21 years ago
|
Flags: blocking1.7a?
Comment 13•21 years ago
|
||
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?
Attachment #137698 -
Flags: review?(caillon) → review+
Comment 14•21 years ago
|
||
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.
Attachment #137698 -
Flags: superreview?(hjtoi-bugzilla) → superreview?(bryner)
Updated•21 years ago
|
Attachment #137698 -
Flags: superreview?(bryner) → superreview+
Comment 15•21 years ago
|
||
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.
Attachment #137698 -
Flags: approval1.7a?
Comment 16•21 years ago
|
||
Comment on attachment 137698 [details] [diff] [review]
Don't allow dropping into file inputs.
a=chofmann for 1.7a
Attachment #137698 -
Flags: approval1.7a? → approval1.7a+
Comment 17•21 years ago
|
||
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Updated•21 years ago
|
Flags: blocking1.7a?
Comment 18•21 years ago
|
||
verified with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b)
Gecko/20040421
Status: RESOLVED → VERIFIED
Comment 19•21 years ago
|
||
Adding Jon Granrose to CC list to help round up QA resources for verification
Comment 20•21 years ago
|
||
Comment on attachment 137698 [details] [diff] [review]
Don't allow dropping into file inputs.
a=blizzard for 1.4.3
Attachment #137698 -
Flags: approval1.4.3+
Updated•21 years ago
|
Whiteboard: [sg:fix]
Comment 22•21 years ago
|
||
Removing security-sensitive flag for bugs on the known-vulnerabilities list
Group: security
Reporter | ||
Updated•12 years ago
|
Keywords: csec-spoof,
sec-high
Whiteboard: [sg:fix]
You need to log in
before you can comment on or make changes to this bug.
Description
•