Closed
Bug 144704
Opened 23 years ago
Closed 23 years ago
javascript: url loaded from bookmark sidebar or manager runs as chrome
Categories
(Core :: Security: CAPS, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: jruderman, Assigned: dveditz)
References
()
Details
Attachments
(1 file)
598 bytes,
patch
|
bryner
:
review+
brendan
:
superreview+
endico
:
approval+
|
Details | Diff | Splinter Review |
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•23 years ago
|
Group: security?
Comment 2•23 years ago
|
||
Any news? Today is the last day for 1.0rc3, which probably means for 1.0.
/be
Assignee | ||
Comment 3•23 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•23 years ago
|
||
Assignee | ||
Comment 5•23 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
Comment 6•23 years ago
|
||
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 7•23 years ago
|
||
Comment on attachment 84409 [details] [diff] [review]
Load javascript URIs safely
r=bryner
Attachment #84409 -
Flags: review+
Comment 8•23 years ago
|
||
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•23 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+
Assignee | ||
Comment 11•23 years ago
|
||
*** Bug 88143 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 12•23 years ago
|
||
Checked into trunk and branch
Updated•22 years ago
|
Group: security?
Comment 13•22 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•22 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.
Description
•