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

VERIFIED FIXED

Status

()

Core
Drag and Drop
VERIFIED FIXED
13 years ago
10 years ago

People

(Reporter: Michael Krax, Assigned: dveditz)

Tracking

({fixed-aviary1.0.1, fixed1.4.5, fixed1.7.6})

Trunk
x86
Windows XP
fixed-aviary1.0.1, fixed1.4.5, fixed1.7.6
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.7.6 +
blocking-aviary1.0.1 +
blocking-aviary1.5 +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:fix] need approvals, URL)

Attachments

(1 attachment)

2.25 KB, patch
jst
: review+
mkaply
: superreview+
Christopher Aillon (sabbatical, not receiving bugmail)
: approval-aviary1.0.1+
Christopher Aillon (sabbatical, not receiving bugmail)
: approval1.7.6+
Details | Diff | Splinter Review
(Reporter)

Description

13 years ago
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 ;)
(Assignee)

Comment 1

13 years ago
->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
(Assignee)

Updated

13 years ago
Blocks: 278184, 278186

Updated

13 years ago
Flags: blocking-aviary1.1? → blocking-aviary1.1+
(Assignee)

Comment 2

13 years ago
Created attachment 173200 [details] [diff] [review]
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.
(Assignee)

Updated

13 years ago
Attachment #173200 - Flags: superreview?(bugs)
Attachment #173200 - Flags: review?(jst)
(Assignee)

Updated

13 years ago
Flags: blocking-aviary1.0.1?
Whiteboard: [sg:fix] → [sg:fix] need review
(Assignee)

Updated

13 years ago
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+

Comment 5

13 years ago
on public website, known by press, opening.
Group: security

Updated

13 years ago
Group: security
(Assignee)

Updated

13 years ago
Attachment #173200 - Flags: superreview?(bugs) → superreview?(mkaply)

Updated

13 years ago
Attachment #173200 - Flags: superreview?(mkaply) → superreview+
Comment on attachment 173200 [details] [diff] [review]
fix tabbrowser drops

sr=me, fwiw
(Assignee)

Updated

13 years ago
Attachment #173200 - Flags: approval1.7.6?
Attachment #173200 - Flags: approval-aviary1.0.1?
(Assignee)

Updated

13 years ago
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+
(Assignee)

Comment 8

13 years ago
Fixed on trunk plus 1.7 and aviary1.0.1 branches
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Keywords: fixed-aviary1.0.1, fixed1.7.6
Resolution: --- → FIXED
(Reporter)

Comment 9

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

Comment 10

13 years ago
Unhiding <http://www.heise.de/newsticker/meldung/56140>
Group: security

Comment 11

12 years ago
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?

Comment 13

12 years ago
(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

12 years ago
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

12 years ago
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

Comment 16

12 years ago
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?
Keywords: fixed1.4.5
(Assignee)

Updated

12 years ago
Blocks: 256195
(Assignee)

Comment 17

12 years ago
awarded a bug bounty
Blocks: 256197
No longer blocks: 256195

Updated

12 years ago
Flags: testcase+

Updated

10 years ago
Flags: in-testsuite+ → in-testsuite?
You need to log in before you can comment on or make changes to this bug.