Closed
Bug 250725
Opened 20 years ago
Closed 20 years ago
Drag-and-dropped link skips CheckLoadURI
Categories
(Core :: DOM: Events, defect, P1)
Tracking
()
RESOLVED
DUPLICATE
of bug 285438
People
(Reporter: jruderman, Assigned: jst)
References
Details
(Whiteboard: [sg:fix])
Attachments
(1 file, 2 obsolete files)
332 bytes,
text/html
|
Details |
Requirement to exploit:
Convince the user to drag something (within the browser window is sufficient).
Impact:
CheckLoadURI bypassed. I don't remember how bad this is.
Reporter | ||
Comment 1•20 years ago
|
||
Demo CSS based on demo in bug 206859.
Reporter | ||
Updated•20 years ago
|
Flags: blocking1.8a2?
Reporter | ||
Comment 2•20 years ago
|
||
The other demo probably only works on Windows. This one uses a chrome: URL
instead of a file: URL.
Attachment #152746 -
Attachment is obsolete: true
Reporter | ||
Comment 3•20 years ago
|
||
If you combine this with bug 250862, this is an arbitrary code execution hole.
See demo in bug 250862 comment 1.
Comment 4•20 years ago
|
||
Dropping a link is considered the same thing as entering it in the URL bar and
is used by folks to load things off their desktop or from an in-browser
directory listing. Maybe the check should be when we start dragging rather than
on the dropping, but we'd have to explain why this was different than copy/paste
into a URL-bar.
I don't see a pressing reason to allow drops of non-document links like
javascript: (are there any others that don't replace the document?), as long as
it doesn't interfere with bookmarklets saved as actual bookmarks.
-> Johnny
Assignee: dveditz → jst
Component: Security: General → DOM: Events
Flags: blocking1.8a3?
Flags: blocking1.7.2?
Flags: blocking-aviary1.0PR?
Reporter | ||
Comment 5•20 years ago
|
||
Btw, this check has to be done for dragged text as well as dragged links.
personally i rely on these drags to work.
i'd rather we fix the status bar and a tooltip to not be forgable or otherwise
obscurable so that people can see what they're actually taking with them.
Reporter | ||
Comment 7•20 years ago
|
||
timeless: stop relying on security holes :)
Updated•20 years ago
|
Flags: blocking-aviary1.0PR? → blocking-aviary1.0PR+
Updated•20 years ago
|
Priority: -- → P1
Updated•20 years ago
|
Flags: blocking1.8a3?
Flags: blocking1.8a3+
Flags: blocking1.8a2?
Flags: blocking1.7.3?
Flags: blocking1.7.3+
Updated•20 years ago
|
Flags: blocking1.8a3+ → blocking1.8a3-
Assignee | ||
Comment 8•20 years ago
|
||
I tested this a bit, and while it's possible to drop a chrome: URL into the
content area, it doesn't seem to be possible to do the same for a javascript: URL.
Personally I don't see how being able to drop a chrome: URL is all that bad, but
being able to drop a javascript: URL would be, but as that doesn't seem
possible, I don't see this as a serious security exploit.
Reporter | ||
Comment 9•20 years ago
|
||
jst: Did you try the demo in bug 250862?
Assignee | ||
Comment 10•20 years ago
|
||
No, I wrote up my own testcase, and obviously something went wrong there... With
that testcase I do see the bug.
I've got a patch that fixes that for Firefox, attaching...
Assignee | ||
Comment 11•20 years ago
|
||
Updated•20 years ago
|
Whiteboard: [have patch]
Assignee | ||
Comment 12•20 years ago
|
||
Comment on attachment 156548 [details] [diff] [review]
Prevent dropping javascript: and data: URLs into firefox.
Moving this to bug 250725 where it belongs.
Attachment #156548 -
Attachment is obsolete: true
Comment 13•20 years ago
|
||
minus on this one since it is now tracked in
http://bugzilla.mozilla.org/show_bug.cgi?id=250862
Updated•20 years ago
|
Flags: blocking-aviary1.0PR+ → blocking-aviary1.0PR-
Updated•20 years ago
|
Whiteboard: [have patch] → [sg:fix]
Reporter | ||
Comment 14•20 years ago
|
||
*** This bug has been marked as a duplicate of 285438 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Updated•20 years ago
|
Group: security
You need to log in
before you can comment on or make changes to this bug.
Description
•