javascript: url loaded from bookmark sidebar or manager runs as chrome

VERIFIED FIXED

Status

()

Core
Security: CAPS
VERIFIED FIXED
15 years ago
15 years ago

People

(Reporter: Jesse Ruderman, Assigned: dveditz)

Tracking

Trunk
x86
Windows 98
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
A javascript: URL loaded from any of the following places runs as chrome:

* bookmarks sidebar
* bookmark manager
* global history window
* global history sidebar

Example: javascript:try{x=String(Components.classes);}catch(er){x=er};x

The weird thing is that bookmarks loaded from these places run as chrome /and/
run in the context of the page in the content area.  How can they be both chrome
and part of the page?

Expected:
* javascript: urls loaded from bookmarks should run as part of the page
* javascript: urls loaded from global history should run as nothing

Bookmarklets run from the bookmarks menu and from the personal toolbar work as
expected.
(Reporter)

Updated

15 years ago
Group: security?
Keywords: nsbeta1+
Whiteboard: [ADT2 RTM]
Dan Veditz has offered to take this one.
Assignee: mstoltz → dveditz
Any news?  Today is the last day for 1.0rc3, which probably means for 1.0.

/be
(Assignee)

Comment 3

15 years ago
I'm just learning my way on the security stuff. I plan on fixing it this week,
but if you want something immediate someone who knows what to look for already
should take it.
(Assignee)

Comment 4

15 years ago
Created attachment 84409 [details] [diff] [review]
Load javascript URIs safely
(Assignee)

Comment 5

15 years ago
This bug is in the utility function openTopWin() which is called lots of places.
Many of them probably suffered from this bug. In addition to the bookmarks and
history problems in this bug, the view image (and background image) problem from
bug 143420 turns out to have the same cause. abCardViewOverlay.js is another one
to look into.

It doesn't look like any places would get broken by this change, but it'd be
good to get a second opinion or some trunk testing before landing this on the
branch.
Status: NEW → ASSIGNED
Adding to the rc3-not-suck list, thanks dveditz.  Does walletOverlay.js need a
similar fix?  I see other foo._content.location{,.href} = ... patterns under
xpfe/components.

/be
Blocks: 143200
Comment on attachment 84409 [details] [diff] [review]
Load javascript URIs safely

r=bryner
Attachment #84409 - Flags: review+
Comment on attachment 84409 [details] [diff] [review]
Load javascript URIs safely

sr=brendan@mozilla.org

I believe this will be approved today for 1.0 branch checkin.  Please get it
into the trunk ASAP.

/be
Attachment #84409 - Flags: superreview+

Comment 9

15 years ago
Comment on attachment 84409 [details] [diff] [review]
Load javascript URIs safely

a=chofmann,scc

please check this in to the  mozilla 1.0 branch by midnight.
Attachment #84409 - Flags: approval+

Comment 10

15 years ago
adding adt1.0.0+ for checkin to the 1.0 branch.
Keywords: adt1.0.0+
(Assignee)

Comment 11

15 years ago
*** Bug 88143 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 12

15 years ago
Checked into trunk and branch
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Keywords: fixed1.0.0
Resolution: --- → FIXED
Group: security?

Updated

15 years ago
Keywords: adt1.0.0+
Whiteboard: [ADT2 RTM]

Comment 13

15 years ago
Verified on 2002-10-11-branch build on Win2000.

Attached URL throws an exception.
Status: RESOLVED → VERIFIED
Keywords: fixed1.0.0 → verified1.0.2
(Assignee)

Comment 14

15 years ago
Fixing verified keyword so queries of which bugs were fixed in what release come
out right: this was fixed for Mozilla 1.0
Keywords: verified1.0.2 → verified1.0.0
You need to log in before you can comment on or make changes to this bug.