Closed
Bug 265176
Opened 20 years ago
Closed 20 years ago
Javascript allows websites to download content without prompt.
Categories
(Core :: DOM: Events, defect, P1)
Core
DOM: Events
Tracking
()
RESOLVED
FIXED
mozilla1.8alpha5
People
(Reporter: mromarkhan, Assigned: dbaron)
References
Details
(Keywords: fixed-aviary1.0, fixed1.7.5, Whiteboard: [sg:low] has patch, has approval, needs landing)
Attachments
(3 files, 2 obsolete files)
624 bytes,
text/html
|
Details | |
6.27 KB,
patch
|
jst
:
review+
jst
:
superreview+
asa
:
approval-aviary+
asa
:
approval1.7.5+
|
Details | Diff | Splinter Review |
541 bytes,
text/html; charset=UTF-8
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.7.3) Gecko/20041014 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.7.3) Gecko/20041014 Firefox/0.10.1
Alt + click downloads a link without
a prompt.
Using dom events, this user
feature can
be emulated.
The result is content from any url
may be downloaded to the default
downloads folder.
Reproducible: Always
Steps to Reproduce:
1. Put code in onload event
Expected Results:
Prompt user,
or filter this
event.
Comment 2•20 years ago
|
||
I think this is a valid concern. It's well-known (at least in security circles)
that JS has the ability to trigger downloads, it's also well-known that Firefox
downloads without prompt, but at least I didn't realize the combination. It
means that you can drop an exe on my desktop and wait for me to be
wondering/curious what it is and execute it, me assuming that I put it there and
it's sane. So, IMHO, this is a security bug.
Implementation:
I don't think "blocking" downloads in onload like popups will work. The popup
blocker is not designed to be bullet-proof (it's not a security feature, only
annoyance prevention), nor do I think it can be. You can always make clicks do
both a download/popup and a page change using JS.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 3•20 years ago
|
||
Note that this is only promptless if the user has not selected Preferences (or
Options) -> Downloads -> Ask me where to save every file.
jst, haven't we done something at some point with checking if events were
JS-generated or not? I couldn't find the code, but I think we've done it before.
I suspect the right place for a nativeness check would be contentAreaClick in
browser.js (which in this case calls handleLinkClick, which calls saveURL).
Assignee | ||
Comment 4•20 years ago
|
||
Since, with the default preferences on Windows, this allows an attacker to place
a file (potentially executable and with a recognizable name and icon) on the
desktop, I think this should block 1.0.
Flags: blocking-aviary1.0?
Comment 5•20 years ago
|
||
May I broaden this discussion a bit (or new bug)? This whole non-prompt download
is dangerous and commonly abused even without JS. Websites pretending to have
homework essays or whatever and trying to install 0900 dialers are very common
in the wild (at least in Germany), and simply link to an exe instead of the page
you expect.
Comment 6•20 years ago
|
||
Marking blocking-aviary1.0 per chofmann's request.
Flags: blocking-aviary1.0? → blocking-aviary1.0+
Comment 7•20 years ago
|
||
What we want here is a check for event.isTrusted (nsIDOMNSEvent::GetIsTrusted())
in the right place(s).
Assignee | ||
Comment 8•20 years ago
|
||
Updated•20 years ago
|
Assignee: events → dbaron
Assignee | ||
Comment 9•20 years ago
|
||
This one doesn't crash. It seems to break middle-mouse paste - not sure why.
I'm also not sure why aDOMEvent can be null.
Attachment #162763 -
Attachment is obsolete: true
Updated•20 years ago
|
Whiteboard: has draft patch
Assignee | ||
Comment 10•20 years ago
|
||
We need to set the trusted flag correctly for click events. I'm really
wondering how anything that used that before ever worked...
Attachment #162769 -
Attachment is obsolete: true
Comment 11•20 years ago
|
||
Comment on attachment 162875 [details] [diff] [review]
patch
r+sr=jst
Attachment #162875 -
Flags: superreview+
Attachment #162875 -
Flags: review+
Assignee | ||
Comment 12•20 years ago
|
||
Assignee | ||
Updated•20 years ago
|
Attachment #162875 -
Attachment description: possible patch → patch
Attachment #162875 -
Flags: approval1.7.x?
Attachment #162875 -
Flags: approval-aviary?
Comment 13•20 years ago
|
||
Comment on attachment 162875 [details] [diff] [review]
patch
a=asa for branches checkins.
Attachment #162875 -
Flags: approval1.7.x?
Attachment #162875 -
Flags: approval1.7.x+
Attachment #162875 -
Flags: approval-aviary?
Attachment #162875 -
Flags: approval-aviary+
Updated•20 years ago
|
Whiteboard: has draft patch → has patch, has approval, needs landing
Assignee | ||
Comment 14•20 years ago
|
||
Fix checked in to trunk, 2004-10-22 00:32 -0700.
Fix checked in to AVIARY_1_0_20040515_BRANCH, 2004-10-22 00:32 -0700.
Fix checked in to MOZILLA_1_7_BRANCH, 2004-10-22 00:33 -0700.
Status: NEW → RESOLVED
Closed: 20 years ago
Keywords: fixed-aviary1.0,
fixed1.7.x
Resolution: --- → FIXED
Assignee | ||
Updated•20 years ago
|
OS: Windows ME → All
Priority: -- → P1
Hardware: PC → All
Target Milestone: --- → mozilla1.8alpha5
Updated•13 years ago
|
Whiteboard: has patch, has approval, needs landing → [sg:low] has patch, has approval, needs landing
You need to log in
before you can comment on or make changes to this bug.
Description
•