Closed Bug 166103 Opened 23 years ago Closed 23 years ago

Possible to get user to paste unexpected value into file control

Categories

(Core :: Layout: Form Controls, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 57770

People

(Reporter: john, Assigned: john)

Details

(Whiteboard: [sg:dupe 57770])

Attachments

(2 files)

Using display: none it is possible to get a user to select things he cannot see. This means that when you paste the value somewhere you get something different. This can be bad in a file control. In a recent security review it was suggested that we fix this by disallowing pasting; this seems like a severe overreaction. I don't think there isn't anything to fix, but if anything we should simply disallow selection of something that is undisplayed. This is a dup of something, but for the life of me I cannot find the duplicate.
Attached file Testcase
this is definitely already filed... I guess the original may be marked confidential, so unfindable.
Attached file Testcase #2
Same trick is also possible with 'overflow:hidden'
Marking security sensitive.
Group: security?
> we should simply disallow selection of something that is undisplayed. This would be a "fix most cases but not all" issue, right? For example, how do you go about preventing such selection for something like: <div style="color: black; background: white"> Select that c<span style="position:absolute; z-index: -1">:\autoexec.b</span>at </div> And there's always the "white on white" trick....
Yes, Mats's trick is the same. "White on white" isn't as big a deal because we presume the user will see the selection when they select it. In short, I don't see what we could do here without a lotta heuristics in our selection or paste algorithm.
I don't consider this a significant threat. Why the user should paste in file upload at all? Anyone who blindly pastes in file upload is asking for trouble.
I agree. It is similar to another exploit I have been considering filing a bug on: "Can trick user into uploading C:\autoexec.bat by writing a page that says 'please type C:\autoexec.bat into the file control below and hit submit'."
One, not too farfetched, way to fix this is to change the filecontrol to disallow typing and only allow picking files using the filepicker. Most Joe Users (and most other users i would think) never types a path anyway. Possibly we could have a pref (hidden or not) to allow typing the path
Hmm, typing maybe. Copy/paste is here to stay, I think. Especially on Linux, but not just there. drag/drop is also going to need to happen, and select / drag is not that different from it.
I type paths a lot when uploading patches. Even more often I paste into the control from text I've selected elsewhere. Please don't force me to use the browse button when I don't need to.
pasting is a good point. But can't you get typing by opening the filepicker and typing the path in there? Since i would consider it fairly uncommon to type, so an extra click might be ok?
I don't remember the last time I used the browse button on a file control, I always type the path, and having to click and deal with the new window (the file picker) would IMO suck, a lot.
Bah! :-)
Here's the dup, complete with a snazzy demo by Jesse. *** This bug has been marked as a duplicate of 57770 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Re: comment 12, this bug is about pasting... I'm not sure there's really a security issue with typing to start with....
Duplicate of a non-confidential bug
Group: security
Whiteboard: [sg:dupe 57770]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: