Closed
Bug 36946
Opened 25 years ago
Closed 23 years ago
location's getter allows spoofing page source
Categories
(Core :: Security, defect, P2)
Tracking
()
VERIFIED
DUPLICATE
of bug 143369
mozilla1.1alpha
People
(Reporter: norrisboyd, Assigned: jst)
References
Details
Subject:
BUG: location's getter allows spoofing page source
Date:
Thu, 20 Apr 2000 15:30:11 +0300
From:
Georgi Guninski <joro@nat.bg>
To:
Norris Boyd <norris@netscape.com>
[Norris, should I post that to bug 36117?]
It is possible to spoof page source using getter and location object.
The code is:
-----------------------------------
<HTML>
<SCRIPT>
location getter = function() { return "http://www.yahoo.com"};
location setter = function(a) { alert("setting to " + a); } ;
</SCRIPT>
Select "View | Page Source"
</HTML>
-----------------------------------
Comment 1•25 years ago
|
||
Seems like a dup of 36117, really a valid comment to add to that bug (but not to
file as a separate bug). Once window.location is protected, these attempts to
define a getter or setter should fail with exceptions being thrown.
/be
Comment 2•25 years ago
|
||
Bulk reassigning most of norris's bugs to mstoltz.
Assignee: norris → mstoltz
Comment 3•25 years ago
|
||
Marking dependent on 36117, marking M17.
Comment 5•25 years ago
|
||
This is not a dup of 36117. The issue here is not assigning a getter cross-
domain, but of redefining a built-in property of the current page. Apparently,
developers depend on some DOM properties being replaceable or modifiable, but
there may be some set of properties (such as location) which should be replaced
or added to. This is not a beta blocker.
No longer depends on: 36117
Comment 6•25 years ago
|
||
Mitch, did you mean to say "there are some properties (such as location) that
should not be replaced"? That sounds good to me, and it entails DOM idlc adding
JSPROP_PERMANENT, perhaps based on an idlc attribute. Cc'ing jst.
/be
Comment 7•25 years ago
|
||
Marking nsbeta3. We need to come up with a list of properties which should be
PERMANENTed for security reasons without breaking too many scripts.
Keywords: nsbeta3
Updated•25 years ago
|
Whiteboard: [nsbeta3+]
Comment 8•24 years ago
|
||
Marking Future. This is a spoofing attack, probably with limited effect, and
fixing it might break some pages. In general, this issue should be looked at
(marking some DOM properties as unable to be replaced) as it may lead to
exploits, but this should not be a stopper.
Comment 9•24 years ago
|
||
Yet another requirement of XPConnect-based-DOM, or DOM idlc if short-term sol'n
is required: a permanent keyword.
I don't see a huge backward compatibility problem for well-known names like
location, which users never claim in their "left-over" part of the global
object's namespace.
/be
Updated•24 years ago
|
QA Contact: czhang → junruh
Comment 11•24 years ago
|
||
Mass changing milestones to Moz0.9.1. Many of these bugs are dependent on the
XPConnected DOM and its associated security UI changes.
Target Milestone: Future → mozilla0.9.1
Comment 12•24 years ago
|
||
Still exists but not a serious exploit, and fixing it may screw up some
functionality. So I'm putting it off.
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Comment 13•24 years ago
|
||
We should also prevent pages from putting getters/setters on
[document.]location.href and document.URL.
Updated•24 years ago
|
Priority: P3 → P1
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Comment 14•24 years ago
|
||
Adding nsBranch keyword as these bugs need to get into RTM.
Keywords: nsBranch
Comment 15•24 years ago
|
||
mitch - if you feel that this security bug is a "must have" for Netscape rtm,
please add [PDT+] to the status whiteboard so this bug can be tracked separately
from all the nsbranch keyword bugs. Thank you.
Comment 16•24 years ago
|
||
This bug as described is not serious enough to be a stop-ship. However, there
may be other exploits caused by the ability to assign getters/setters to
built-in properties like window.location. We're continuing to look for those.
Keywords: nsBranch
Comment 17•24 years ago
|
||
Target is now 0.9.4, Priority P2.
Priority: P1 → P2
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Comment 18•23 years ago
|
||
Not critical for 0.9.4, moving to 0.9.5.
Group: netscapeconfidential?
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Comment 19•23 years ago
|
||
See also bug 87428 (link toolbar). Gerv is running into trouble trying to get
the current URL securely.
Comment 20•23 years ago
|
||
time marches on...retargeting to 0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Comment 21•23 years ago
|
||
Moving the most time-critical bugs and minor security fixes to 0.9.7
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Comment 22•23 years ago
|
||
Mass change: It appears that several bugs got accidentally opened up as part of
a mass change - see bug 107718 (now fixed). Moving back to security-sensitive
group. These were open for about 10 days.
Group: security?
Updated•23 years ago
|
Target Milestone: mozilla0.9.7 → mozilla0.9.9
Comment 25•23 years ago
|
||
Patch in 143369 should fix this -- jst, if true, please close as a dup.
/be
Assignee: mstoltz → jst
Status: ASSIGNED → NEW
Assignee | ||
Comment 26•23 years ago
|
||
Yup, this is now fixed too.
*** This bug has been marked as a duplicate of 143369 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Updated•22 years ago
|
Group: security?
You need to log in
before you can comment on or make changes to this bug.
Description
•