Closed Bug 36946 Opened 24 years ago Closed 22 years ago

location's getter allows spoofing page source

Categories

(Core :: Security, defect, P2)

Product:
Core
Component:
Security
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 143369
Milestone:
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>
-----------------------------------
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
Bulk reassigning most of norris's bugs to mstoltz.
Assignee: norris → mstoltz
Marking dependent on 36117, marking M17.
Status: NEW → ASSIGNED
Depends on: 36117
Target Milestone: --- → M17
Assigning QA to czhang
QA Contact: junruh → czhang
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
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
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
Whiteboard: [nsbeta3+]
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.
Group: netscapeconfidential?
Keywords: nsbeta3
Whiteboard: [nsbeta3+]
Target Milestone: M17 → Future
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
QA Contact: czhang → junruh
Mass changing QA to ckritzer.
QA Contact: junruh → ckritzer
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
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
We should also prevent pages from putting getters/setters on 
[document.]location.href and document.URL.
Priority: P3 → P1
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Adding nsBranch keyword as these bugs need to get into RTM.
Keywords: nsBranch
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.
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
Target is now 0.9.4, Priority P2.
Priority: P1 → P2
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Not critical for 0.9.4, moving to 0.9.5.
Group: netscapeconfidential?
Target Milestone: mozilla0.9.4 → mozilla0.9.5
See also bug 87428 (link toolbar).  Gerv is running into trouble trying to get 
the current URL securely.
time marches on...retargeting to 0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Moving the most time-critical bugs and minor security fixes to 0.9.7
Target Milestone: mozilla0.9.6 → mozilla0.9.7
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?
Target Milestone: mozilla0.9.7 → mozilla0.9.9
Mozilla1.0
Target Milestone: mozilla0.9.9 → mozilla1.0
Mozilla1.1
Target Milestone: mozilla1.0 → mozilla1.1
Patch in 143369 should fix this -- jst, if true, please close as a dup.

/be
Assignee: mstoltz → jst
Status: ASSIGNED → NEW
Yup, this is now fixed too.

*** This bug has been marked as a duplicate of 143369 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Group: security?
vrfy dupe
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.