The status bar domain name display is not updated when the "back" button is clicked (bfcache, XSLT)

VERIFIED FIXED in Firefox 2

Status

()

Firefox
Security
--
major
VERIFIED FIXED
13 years ago
11 years ago

People

(Reporter: Tyler Close, Assigned: Brian Ryner (not reading))

Tracking

(Blocks: 1 bug, {verified1.8.0.2, verified1.8.1})

1.5.0.x Branch
Firefox 2
verified1.8.0.2, verified1.8.1
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.8.0.1 -
blocking1.8.0.2 +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:low] spoof [kerh-bra] requires 322683[rft-dl], URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

The onSecurityChange() notification is not sent when "Back" button is clicked.

Reproducible: Always

Steps to Reproduce:
1. Visit an https page
2. Click on a contained hyperlink to an https page at another site
3. Click the "back" button

Actual Results:  
You are now looking at the first https page; however, the domain name display at the right hand side of the status bar still shows the domain name from the linked to https page.

Expected Results:  
The domain name display should show the domain name of the current web page.

This happens because the onSecurityChange() event of the nsIWebProgressListener interface does not get fired when you click the "back" button.
(Reporter)

Updated

13 years ago
Version: unspecified → 1.5 Branch

Comment 1

13 years ago
WFM Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051110 Firefox/1.5
Issues like these are very often caused by misbehaving extensions. Could you try reproducing this in Safe mode?

http://kb.mozillazine.org/Safe_Mode
(Reporter)

Comment 3

13 years ago
The bug seems to have something to do with the use of XSLT on the linking page. For example, the bug can always be reproduced when visiting this page:

<https://yurl.net/id/backtest>

The bug also occurs when using the Firefox Safe mode.

Comment 4

13 years ago
Gavin I'm going to confirm this for now, you can back that out later if need be.

I deffinantly see the issue described in that test case.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: MacOS X → All
Hardware: Macintosh → All
This is a bfcache issue... doesn't happen with browser.sessionhistory.max_total_viewers = 0.

Comment 6

13 years ago
WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051120 Firefox/1.6a1
Flags: blocking1.8.0.1?
Whiteboard: [sg:needinfo] spoof

Comment 7

13 years ago
Oops, I had disabled bfcache.  I can reproduce now.
Blocks: 274784
Whiteboard: [sg:needinfo] spoof → [sg:spoof]
Blocks: 130949
Group: security
Whiteboard: [sg:spoof] → [sg:low] spoof
If the back navigation takes you to a non-ssl page there's no spoofing. This lets you spoof one SSL page as another SSL page in the status bar (the address bar, of course, is correct).

It's not hard for a spoofer to get a domain-controlled SSL cert.
(In reply to comment #8)
> If the back navigation takes you to a non-ssl page there's no spoofing.

Sorry, Tyler was right in comment 3: the backtest page using xslt reproduces the problem when hosted locally non-ssl, other random starting pages don't have the problem regardless of SSL or not.
(Reporter)

Comment 10

13 years ago
After clicking the "back" button, try clicking the lock icon in the status bar to display the security page info. The first paragraph in the "Security" tab says:

"The web site yurl.net supports authentication for the page you are viewing. The identity of this web site has been verified by Verisign, Inc., a certificate authority you trust for this purpose."

yurl.net doesn't have a certificate from Verisign, Inc. The dialog appears to be using a cached value for the domain name and the certificate authority name taken from the vsci.hpl.hp.com certificate (the linked to site). That's a second bug. The dialog should be taking the domain name value from the CN field of the displayed certificate. Doing this at least ensures that the dialog is presenting self consistent information, rather than fiction.

Comment 11

13 years ago
Here are two ways a site like https://yurl.net/id/backtest could exploit this to spoof https://bugzilla.mozilla.org/:

(1) With an alert

javascript: function invoke() { location.href = "https://bugzilla.mozilla.org"; alert("Please wait"); history.back(); } setTimeout(invoke, 200); void 0

(2) With a temporary, possibly hidden popup

javascript:function foo() { opener.location = "https://bugzilla.mozilla.org"; setTimeout(function() { opener.history.back(); close(); }, 1500); } var b = document.createElement("button"); b.appendChild(document.createTextNode("Click me!")); b.onclick = function() { open('data:text/html,<script>' + foo + 'foo()</script>Please wait','','width=100,height=100,location=no,directories=no,status=no,menubar=no'); }; document.body.appendChild(b); void 0

To test, just load https://yurl.net/id/backtest, paste one of those bookmarklets, and keep an eye on the status bar.

Using alert() has the advantage of being fast and not requiring previous user interaction with the evil page.  Using a popup has the advantage that the user might not see it at all, especially if you use window.focus() to keep the main window in front.
(Reporter)

Comment 12

13 years ago
I filed this bug before the 1.5 release went out. I am a little surprised the two bugs weren't fixed before putting out the 1.5 release. It looks like we've isolated the problems. Is there a plan for releasing a fix for this bug?

I was also wondering how many hidden "Security-Sensitive" bugs are currently outstanding against the Firefox 1.5 release.

Comment 13

13 years ago
While it's true that you filed this bug before Firefox 1.5 was released, Firefox 1.5 RC3 had already been released and was on track to become Firefox 1.5.  If we had to respin for a new RC and restart our (unfortunately week-long) release process every time a security hole was discovered, Firefox 1.5 could have been delayed for quite a while.  Firefox 1.5 itself contains important security fixes and an overhaul of the software update system, giving us one reason to not want to delay the release of Firefox 1.5 so it could pick up a fix for this bug.  Sorry for not explaining this earlier.

I have nominated this bug to block Gecko 1.8.0.1 (Firefox 1.5.0.1), which is expected to be released in late January.

FWIW, there are 150 security-sensitive bugs in the "new", "reopened", or "assigned" states, and 37 in the "unconfirmed" state.  Those lists include a lot of bugs that aren't security holes (such as metabugs, reminders to audit certain features, and reports without useful information), but they also include more security holes at least as severe as this one than I'd like.

Comment 14

13 years ago
CCing some people who have fixed lock icon bugs recently and might be able to help figure out what's going on here.

Updated

13 years ago
Whiteboard: [sg:low] spoof → [sg:low] spoof [kerh-bra]

Updated

13 years ago
Flags: blocking1.9a1?

Comment 15

13 years ago
I can only reproduce the problem when navigating back or forward from another https site to https://yurl.net/id/backtest while bfcache is enabled.

Comment 16

13 years ago
-> bryner

I also only see this bug when I have bfcache enabled.
Assignee: nobody → bryner
Flags: blocking1.8.1?
I thought this might have been introduced by bug 301516, but it dates back to the landing of fastback (between 2005-05-04 07:00 and 2005-05-04 16:00) so none of the subsequent fixes seem to have affected it.
(Assignee)

Comment 19

13 years ago
Yeah, this only happens when XSLT is used.  When the result document is created, StartDocumentLoad is never called on it.  This should be fine, since we're not actually going to load anything.  But I do think we need to get the channel that's created in URIUtils::ResetWithSource to be the new document's mChannel, or we won't have any channel to use for the progress notifications when restoring the result doc.

Boris, do you think it makes sense to set mChannel automatically when Reset() is called, or should we have a separate way to do this?
(Assignee)

Comment 20

13 years ago
Created attachment 207372 [details] [diff] [review]
patch
Attachment #207372 - Flags: superreview?(bzbarsky)
Attachment #207372 - Flags: review?(darin)
Comment on attachment 207372 [details] [diff] [review]
patch

Seems reasonable if you make the same change to txMozillaTextOutput::createResultDocument
Attachment #207372 - Flags: superreview?(bzbarsky) → superreview+
(Assignee)

Comment 22

13 years ago
Comment on attachment 207372 [details] [diff] [review]
patch

Oops, darin is still on vacation.  I'm going to check this in with r+sr=bzbarksy, assuming that's ok.
Attachment #207372 - Flags: review?(darin)
(Assignee)

Comment 23

13 years ago
checked in
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
(Assignee)

Comment 24

13 years ago
Comment on attachment 207372 [details] [diff] [review]
patch

requesting branch approvals.  this patch should be fairly safe and does not break any APIs.
Attachment #207372 - Flags: approval1.8.1?
Attachment #207372 - Flags: approval1.8.0.1?
Might be worth posting the full patch (with the other file that needs to be included) so we make sure to fix that on branch...
Whiteboard: [sg:low] spoof [kerh-bra] → [sg:low] spoof [kerh-bra] needs branch patch?
(Assignee)

Comment 26

13 years ago
Created attachment 207531 [details] [diff] [review]
full patch that was checked in
Attachment #207372 - Attachment is obsolete: true
Attachment #207531 - Flags: approval1.8.1?
Attachment #207531 - Flags: approval1.8.0.1?
Attachment #207372 - Flags: approval1.8.1?
Attachment #207372 - Flags: approval1.8.0.1?

Comment 27

13 years ago
Is the onSecurityChange() notification accessible through Javascript?
Chrome JS, probably yes.  Content JS, no.
we want more baking, -> 1.8.0.2
You can check reviewed patches into 1.8.1 (ff2) without extra approvals for now
Flags: blocking1.8.0.2?
Flags: blocking1.8.0.1?
Flags: blocking1.8.0.1-
Attachment #207531 - Flags: approval1.8.1?
Attachment #207531 - Flags: approval1.8.1+
Attachment #207531 - Flags: approval1.8.0.1?
Attachment #207531 - Flags: approval1.8.0.1-
(Assignee)

Comment 30

13 years ago
checked in on MOZILLA_1_8_BRANCH
Keywords: fixed1.8.1
Target Milestone: --- → Firefox 2
(In reply to comment #29)
> You can check reviewed patches into 1.8.1 (ff2) without extra approvals for now

I have been corrected: 1.8.1 needs approvals, see updated tree rules on tinderbox. Drivers approved this fix for 1.8.1 though.
Whiteboard: [sg:low] spoof [kerh-bra] needs branch patch? → [sg:low] spoof [kerh-bra] requires 322683

Comment 33

13 years ago
v yurl testcase 1.8.1, 1.9a1 windows/linux
Status: RESOLVED → VERIFIED
Keywords: fixed1.8.1 → verified1.8.1

Updated

13 years ago
Flags: testcase?
Blocks: 256195

Updated

13 years ago
Flags: testcase? → testcase+
Flags: blocking1.8.0.2? → blocking1.8.0.2+
Comment on attachment 207531 [details] [diff] [review]
full patch that was checked in

This needs to land, if it's going to block... ;)
Attachment #207531 - Flags: approval1.8.0.2?
Comment on attachment 207531 [details] [diff] [review]
full patch that was checked in

approved for 1.8.0 branch, a=dveditz for drivers
Attachment #207531 - Flags: approval1.8.0.2? → approval1.8.0.2+
Checked this in on 1.8.0.2 branch.
Keywords: fixed1.8.0.2

Updated

13 years ago
Whiteboard: [sg:low] spoof [kerh-bra] requires 322683 → [sg:low] spoof [kerh-bra] requires 322683[rft-dl]
Summary: The status bar domain name display is not updated when the "back" button is clicked. → The status bar domain name display is not updated when the "back" button is clicked (bfcache, XSLT)
verified on the 1.8.0.2 branch using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060306 Firefox/1.5.0.2. I tried to reproduce using the steps in the initial report and I don't see the problem. adding keyword.
Keywords: fixed1.8.0.2 → verified1.8.0.2
Group: security

Updated

11 years ago
Flags: in-testsuite+ → in-testsuite?

Updated

11 years ago
Flags: blocking1.9a1?
You need to log in before you can comment on or make changes to this bug.