Closed Bug 130394 Opened 22 years ago Closed 22 years ago

Location bar spoofing using document.write

Categories

(Core Graveyard :: Security: UI, defect, P1)

1.0 Branch
defect

Tracking

(Not tracked)

VERIFIED FIXED
psm2.2

People

(Reporter: security-bugs, Assigned: KaiE)

References

(Blocks 1 open bug, )

Details

(Whiteboard: [sg:openended])

This is pretty serious. Open a window to a secure site (like a bank), then
document.write some content into that window. The content is replaced, but the
URL bar, lock icon, and certificate information remain. We may need to return to
a wysiwyg: URL scheme for document.open'ed pages. At the very least, we need to
clear the SSL status when we document.open.
Adding keywords, setting milestone Moz1.0
Status: NEW → ASSIGNED
Keywords: nsbeta1
Target Milestone: --- → mozilla1.0
My bad...wysiwyg URLs have already been implemented, and the URL bar now shows
the  URL of the page containing the script that did the document.open. This is
correct. However, we still need to re-evaluate the SSL UI status when
document.open() is called. Reassigning to PSM and CC'ing some key people.
Component: Security: General → Client Library
Product: Browser → PSM
Target Milestone: mozilla1.0 → ---
Version: other → 2.2
Over to stephane
Assignee: mstoltz → ssaux
Status: ASSIGNED → NEW
QA Contact: bsharma → junruh
David.
Assignee: ssaux → ddrinan
Keywords: nsbeta1nsbeta1+
please look at bug 125225. The patch there could fix this. 
this bug blocks the lock icon tracking bug.
Blocks: lockicon
kai
Assignee: ddrinan → kaie
Priority: -- → P1
Target Milestone: --- → 2.2
The suggested patch in bug 130949 seems to fix this bug. Testing required.
Please try to get this in for Mozilla 1.0.
Keywords: mozilla1.0
fix is in the parent bug.
This should be fixed by the patch checked in with bug 130949.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Verified fixed.
Status: RESOLVED → VERIFIED
We should either reopen this bug or open a new one.

Because I did a lot of work on the lock icon behaviour recently, I thought it
makes sense to try this testcase again.

I now see a strange new behaviour, that is similar to the originally reported
problem.

The problem appears only the first time you try it during a session.


Go to:
  http://warp.mcom.com/u/mstoltz/bugs/spoof.html

Actual behaviuor:
- the page loads
- the new window opens
- a crypto warning is shown
- the "bank of america" page loads and is displayed
- the URL location bar displays the "bank of america" URL.

BUT

The displayed content is a mixture of the "bank of america" content and in
addition, the JavaScript output

  Would you believe this is BofA?

is shown on top of the page!

I can always reproduce this on Linux, but only when trying the first time after
starting the browser.

This might be related to timing. If you don't see it immediately, try it again.
Reopening bug per comment 13 -- this doesn't sound fixed in 1.0
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
This sounds very serious. Can anyone reproduce it? Too bad the test page is
behind the firewall.
I cannot reproduce this. After the windows are opened. BofA does not appear in
the URL bar.
I haven;t tried to reproduce this specifically, but I fixed a urlbar spoofing
bug for document.write() pages last week.
Maybe I did confuse you, please re-read comment 13.

The original problem, spoofing in the URL bar, seems fixed.

The new problem is NOT in the URL bar, it is in the "Content area" of the
displayed page. See comment 13 for the description.

I haven't tried since a while. If you can not reproduce the problem, I'll try
again using a recent version.
WFM. A new window does not even open with the 9/27 Win2000 trunk build.
Status: REOPENED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → WORKSFORME
Verified.
Status: RESOLVED → VERIFIED
Reopening. The fact that "window open" does temporarily not work, does not mean
this bug is fixed. (I suspect you either are currently blocking popup ads or
there is a regression somewhere else in JavaScript code.)
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
Ok, I'm convinced, I'm marking it back to fixed.

I tried to reproduce my new problem, but I no longer can.
Status: REOPENED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
Verified with the 10/14 trunk build.
Status: RESOLVED → VERIFIED
removing security flag from long-fixed bug
Group: security
Product: PSM → Core
Version: psm2.2 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.