As a security precaution, we have turned on the setting "Require API key authentication for API requests" for everyone. If this has broken something, please contact bugzilla-admin@mozilla.org
Last Comment Bug 250862 - browser accepts dragged javascript: links (same-origin security hole)
: browser accepts dragged javascript: links (same-origin security hole)
Status: VERIFIED FIXED
[sg:fix]
: fixed-aviary1.0, fixed1.4.4, fixed1.7.3
Product: Core
Classification: Components
Component: Document Navigation (show other bugs)
: 1.0 Branch
: x86 Windows XP
: P2 normal (vote)
: ---
Assigned To: Johnny Stenback (:jst, jst@mozilla.com)
:
: Andrew Overholt [:overholt]
Mentors:
Depends on: 250725
Blocks:
  Show dependency treegraph
 
Reported: 2004-07-11 04:17 PDT by Jesse Ruderman
Modified: 2007-11-06 11:44 PST (History)
13 users (show)
dveditz: blocking1.7.5+
bugs: blocking‑aviary1.0PR+
asa: blocking1.8a3-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
demo for firefox (877 bytes, text/html)
2004-07-11 04:24 PDT, Jesse Ruderman
no flags Details
Prevent dropping javascript: and data: URLs into firefox. (1.47 KB, patch)
2004-08-19 16:53 PDT, Johnny Stenback (:jst, jst@mozilla.com)
no flags Details | Diff | Splinter Review
Same thing for both Firefox and SeaMonkey (2.92 KB, patch)
2004-08-19 17:00 PDT, Johnny Stenback (:jst, jst@mozilla.com)
caillon: review+
dveditz: superreview+
asa: approval‑aviary+
asa: approval1.7.5+
Details | Diff | Splinter Review

Description User image Jesse Ruderman 2004-07-11 04:17:55 PDT
Firefox accepts drags of javascript: links, allowing same-origin violations. 
Exploiting this hole requires getting the user to cooperate with instructions,
but does not require the user to do anything likely to make them suspicious.

I think Seamonkey has the same hole.

Combined with 250725 (Drag-and-dropped link skips CheckLoadURI), this
same-origin hole becomes an arbitrary code execution hole.
Comment 1 User image Jesse Ruderman 2004-07-11 04:24:17 PDT
Created attachment 152856 [details]
demo for firefox

This demo works in Firefox and Mozilla, but it works better in Firefox.
Comment 2 User image Jesse Ruderman 2004-07-12 15:29:29 PDT
Mike, this should block Mozilla 1.7.2.
Comment 3 User image Daniel Veditz [:dveditz] 2004-07-13 14:44:15 PDT
-> Browser product so we can make it block more releases
Comment 4 User image Ben Goodger (use ben at mozilla dot org for email) 2004-07-22 13:04:56 PDT
+ing for dveditz to look at. 
Comment 5 User image Daniel Veditz [:dveditz] 2004-07-28 14:09:27 PDT
Why do we allow privileged chrome inside a browser control? A few things
(about:config, about:plugins) would have to be moved into a chrome windows of
their own if we did that, but might be way safer in the long run.

Is javascript: the only scheme that isn't a complete replacement document?
Comment 6 User image Jesse Ruderman 2004-07-28 15:57:29 PDT
We should also block data: URLs here, since like javascript: URLs, they inherit
their security context from the previous page.  (The fact that they can also act
as replacement URLs caused both Mozilla and IE to be vulnerable to bug 88167.)
Comment 7 User image chris hofmann 2004-08-16 16:26:18 PDT
dan any updates on when a patche will be ready for this?
Comment 8 User image georgi - hopefully not receiving bugspam 2004-08-19 11:17:30 PDT
why not disallow dragging into location bar if the protocol or the begining of
the URL is not "http" or "https" ?

i don't see any functional advantage of dragging into location bar compared to
clicking or middle clicking.
Comment 9 User image georgi - hopefully not receiving bugspam 2004-08-19 11:24:01 PDT
sorry, didn't see the demo.

obviously the problem is not the location bar.
Comment 10 User image Johnny Stenback (:jst, jst@mozilla.com) 2004-08-19 16:53:35 PDT
Created attachment 156549 [details] [diff] [review]
Prevent dropping javascript: and data: URLs into firefox.
Comment 11 User image Johnny Stenback (:jst, jst@mozilla.com) 2004-08-19 17:00:34 PDT
Created attachment 156550 [details] [diff] [review]
Same thing for both Firefox and SeaMonkey
Comment 12 User image Daniel Veditz [:dveditz] 2004-08-19 17:25:52 PDT
Comment on attachment 156550 [details] [diff] [review]
Same thing for both Firefox and SeaMonkey

sr=dveditz
Comment 13 User image Daniel Veditz [:dveditz] 2004-08-19 18:19:44 PDT
I checked the other onDrops in the codebase (except calendar) and everything
else javascript urls are either already rejected or harmless (e.g. setting your
home page to a js url).
Comment 14 User image Asa Dotzler [:asa] 2004-08-20 15:51:47 PDT
Comment on attachment 156550 [details] [diff] [review]
Same thing for both Firefox and SeaMonkey

a=asa for branch landings.
Comment 15 User image georgi - hopefully not receiving bugspam 2004-08-21 00:01:51 PDT
looks like with the patch dragging "file" and "chrome" urls still may work which
may lead to trouble.

why not use a safe whitelist?
Comment 16 User image Johnny Stenback (:jst, jst@mozilla.com) 2004-08-24 17:29:12 PDT
We decided against blocking chrome for now, we'll need to investigate the
results of blocking that more before flipping the switch. Bug 250725 is for
tracking that part, but that, in combination with this, is really bad, thus the
fix for this to start with.
Comment 17 User image Johnny Stenback (:jst, jst@mozilla.com) 2004-08-26 00:49:05 PDT
Fixed on trunk, aviary, and 1.7 branches.
Comment 18 User image Johnny Stenback (:jst, jst@mozilla.com) 2004-08-26 18:21:10 PDT
Fixed on the 1.7.2 branch now too.
Comment 19 User image Asa Dotzler [:asa] 2004-09-13 11:21:38 PDT
Verified with Firefox 0.10 and Mozilla 1.7.3 on windows XP
Comment 20 User image Tracy Walker [:tracy] 2004-12-16 12:31:44 PST
verified windows 1.7.5 12/15
Comment 21 User image Sylvain Pasche 2007-09-14 03:51:16 PDT
What about images in data: URL's?

It could be useful to allow these, as right now there's a little incoherence: you can drag file: or http: based images but not data: ones.

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