Closed Bug 280056 Opened 15 years ago Closed 15 years ago

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

Categories

(Core :: DOM: Drag & Drop, defect)

x86
Windows XP
defect
Not set

Tracking

()

VERIFIED FIXED

People

(Reporter: mikx, Assigned: dveditz)

References

()

Details

(Keywords: fixed-aviary1.0.1, fixed1.4.5, fixed1.7.6, Whiteboard: [sg:fix] need approvals)

Attachments

(1 file)

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 ;)
->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
Assignee: bugs → dveditz
Status: UNCONFIRMED → NEW
Component: Tabbed Browser → Drag and Drop
Ever confirmed: true
Flags: blocking-aviary1.1?
Product: Firefox → Core
Whiteboard: [sg:fix]
Version: unspecified → Trunk
Flags: blocking-aviary1.1? → blocking-aviary1.1+
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.
Attachment #173200 - Flags: superreview?(bugs)
Attachment #173200 - Flags: review?(jst)
Flags: blocking-aviary1.0.1?
Whiteboard: [sg:fix] → [sg:fix] need review
Flags: blocking1.7.6?
Plussing.  We should get this on the branches.
Flags: blocking1.7.6?
Flags: blocking1.7.6+
Flags: blocking-aviary1.0.1?
Flags: blocking-aviary1.0.1+
Comment on attachment 173200 [details] [diff] [review]
fix tabbrowser drops

r=jst
Attachment #173200 - Flags: review?(jst) → review+
on public website, known by press, opening.
Group: security
Group: security
Attachment #173200 - Flags: superreview?(bugs) → superreview?(mkaply)
Attachment #173200 - Flags: superreview?(mkaply) → superreview+
Comment on attachment 173200 [details] [diff] [review]
fix tabbrowser drops

sr=me, fwiw
Attachment #173200 - Flags: approval1.7.6?
Attachment #173200 - Flags: approval-aviary1.0.1?
Whiteboard: [sg:fix] need review → [sg:fix] need approvals
Comment on attachment 173200 [details] [diff] [review]
fix tabbrowser drops

a=caillon for both branches.
Attachment #173200 - Flags: approval1.7.6?
Attachment #173200 - Flags: approval1.7.6+
Attachment #173200 - Flags: approval-aviary1.0.1?
Attachment #173200 - Flags: approval-aviary1.0.1+
Fixed on trunk plus 1.7 and aviary1.0.1 branches
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Since the bug is fixed i will make it public tonight. Just to let you now
beforehand.
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.
Why does that not seem like a real fix?
(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?
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.
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.

Status: RESOLVED → VERIFIED
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?
Blocks: sbb?
awarded a bug bounty
Blocks: sbb+
No longer blocks: sbb?
Flags: testcase+
Flags: in-testsuite+ → in-testsuite?
You need to log in before you can comment on or make changes to this bug.