280056 - When dropping a javascript link to a tab, the script runs in the security context of the site currently displayed in the tab

Status: VERIFIED FIXED

(Core :: DOM: Copy & Paste and Drag & Drop, defect)

Description

[Michael Krax]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

The javascript security manager usually prevents that a javascript: URL from one
host is opened in a window displaying content from another host. But when the
link is dropped to a tab the security manager does not kick in. Probably it is
treated like the javascript: URL was typed by the user - which also does not
trigger the security manager check. 

Reproducible: Always

Steps to Reproduce:
1. Open http://www.mikx.de/firetabbing/
2. Drop the example links to other tabs

Actual Results:  
The scripts are running in the security context of the site currently displayed
in the tab

Expected Results:  
The script should run in its own security context (e.g. about:blank) or the
javascript security manager should kick in (just like it does when you try a
window.location='javascript:' across different hosts).

Tabbed browsing is a great feature to organize mutliple website, but after a
while also tabs become too much. Now you have two options: Close tabs and open
new ones (CTRL+W to close a tab, followed by a CTRL+click on a link to open a
new one), or just recycle already open tabs by dragging links to them - the
solution i prefer.

Dropping links to tabs containing other websites is a common workflow. Well, at
least to me ;)

Comment 1

[Daniel Veditz [:dveditz]]

->Core

Arg! this was supposed to be fixed by bug 250862. Is there something we could do
that's better than hacking each onDrop handler? How many more do we need to
patch? (obviously the one in tabbrowser.xml)

http://lxr.mozilla.org/mozilla/search?string=ondrop

Comment 2

[Daniel Veditz [:dveditz]]

Attachment: fix tabbrowser drops

Makes tabbrowser drop restrictions match those added to content area for bug
250862. I checked the other browser drop targets (go button, urlbar, livefeeds,
home button, download button, etc) and they all appear safe to allow
javascript: urls.

Need to check the mail drop targets.

Comment 3

[Christopher Aillon (sabbatical, not receiving bugmail)]

Plussing.  We should get this on the branches.

Comment 4

[Johnny Stenback (:jst)]

Comment on attachment 173200 [details] [diff] [review]
fix tabbrowser drops

r=jst

Comment 5

[Ben Bucksch (:BenB)]

on public website, known by press, opening.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 173200 [details] [diff] [review]
fix tabbrowser drops

sr=me, fwiw

Comment 7

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 173200 [details] [diff] [review]
fix tabbrowser drops

a=caillon for both branches.

Comment 8

[Daniel Veditz [:dveditz]]

Fixed on trunk plus 1.7 and aviary1.0.1 branches

Comment 9

[Michael Krax]

Since the bug is fixed i will make it public tonight. Just to let you now
beforehand.

Comment 10

[Ben Bucksch (:BenB)]

Unhiding <http://www.heise.de/newsticker/meldung/56140>

Comment 11

[HJ]

Killing ondrop for javascript: isn't a real solution, it seems more like a quick
hack to fix a possible security issue. There must be a better way to solve this
issue, without killing ondrop completely.

Comment 12

[Johnny Stenback (:jst)]

Why does that not seem like a real fix?

Comment 13

[HJ]

(In reply to comment #12)
> Why does that not seem like a real fix?

You should still be able to drag javascript: links to new tabs, or the tab bar,
but that no longer works with this 'fix', right?

Comment 14

[Juha-Matti Laurio]

This was (is) assigned as Secunia ID 14160;

http://secunia.com/advisories/14160/
(Mozilla / Firefox Three Vulnerabilities)

marked as "The vulnerabilities have been fixed in the CVS repository" on 8th
February, 2005.

Comment 15

[Jay Patel [:jay]]

Verified Fixed on 2/21 builds for Aviary 1.0.1, Mozilla 1.7.6, and both Trunk. 
The testcases at http://www.mikx.de/firetabbing/ no longer allow you to execute
the js in tabs.  

HJ:  I haven't had time to thoroughly test this, so I can't say whether you can
no longer drag javascript: urls to tabs/url bar/etc at all (according to comment
#2, this fix just puts sticter restrictions on cross-host js execution), but
please feel free to test this out in any ways that you are accustomed to using
that feature and see what works for you.

Perhaps someone else can better explain whether any drag n drop of js is still
intact and exactly what those restrictions are.  Bug 250862 provides some clues.

Comment 16

[HJ]

Someone should look at this code snip again:

+            if (!url || !url.length || url.indexOf(" ", 0) != -1 ||
+                /^\s*(javascript|data):/.test(url))

1) why do you need \s* if you already have url.indexOf(" ", 0) != -1 ?
2) new tabs/tab bar are save targets, so why did you disable them?

Comment 17

[Daniel Veditz [:dveditz]]

awarded a bug bounty