Closed Bug 276720 Opened 20 years ago Closed 19 years ago

wrong behavior with "http/1.1 204 no content"

Categories

(Core :: Security, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla1.8beta1

People

(Reporter: delete-account-8757, Assigned: darin.moz)

References

(Blocks 1 open bug, )

Details

(Keywords: fixed-aviary1.0.1, fixed1.7.6, Whiteboard: [sg:fix])

Attachments

(3 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217

If a website returns a "Http/1.1 204 No Content" header to the browser, Mozilla
will not replace the page you were visiting. However, the browser will display
the new address in the address bar.

So, if you are visiting http://whateversite.com and then you click on a link to
https://nexus.passport.com/, Mozilla will display "https://nexus.passport.com/"
in your address bar. Mozilla will also display a lock icon in the status bar. If
you double-click on the lock, Mozilla will display a dialog box saying :

"The website whateversite.com supports authentication for the page you are
visiting..."

If you click on the View button, Mozilla shows nexus.passport.com's certificate.

Firefox goes even further by highlighting the address bar and adding a lock icon
near the address. A lock is also added to the status bar beside the string 
"whateversite.com".

I will post a screenshot later.

I could confirm this bug in Firefox 1.0 and Mozilla 1.7.5.

Reproducible: Always

Steps to Reproduce:
1. Go to www.mozilla.org for instance.
2. In your address bar, type the URI of any page who returns a HTTP 204 header.
   (I recommend you to use a HTTPS page)
3. Look at your address bar, check the status bar for a lock icon.

Actual Results:  
Mozilla kept the "204" URI in the address bar, but added lock icons to the
interface.

Expected Results:  
Mozilla should update the URL to match the one of the web page visited by the
user. It should not add locks saying that the content is secure.
Correction : Mozilla will *not* change the contents of the address bar when you
click on a link who returns "http 204 no content". This was an error during my
tests.

However, Mozilla will still add lock icons to the interface (see the screenshot).
Attached file Test page for this bug
This replaces the screenshot i had posted. sorry for all this spam.
Attachment #170060 - Attachment is obsolete: true
hm, obviously not - still seeing this in a trunk build (linux)
OS: Windows XP → All
-> Darin
Assignee: dveditz → darin
Hmm.. I don't get it.  204 responses are dropped before ever entering content
dispatch, so they never have LOAD_TARGETED set.

Confirming bug, but I'm really not sure where the security UI is getting its
notifications from.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.8b?
Hardware: PC → All
This sounds like it could be leveraged to spoof the user in a similar fashion to
bug 278003.  Marking Security-Sensitive.

For example:

Load http://www.not-paypal.com/ which is a fake paypal.com, and then load some
https://www.paypal.com/link/that/happens/to/return/204 (assuming paypal.com has
such a link somewhere on their site).
Group: security
Status: NEW → ASSIGNED
forget i mentioned paypal... the fact that this can be used to spoof
passport.com sounds plenty serious to me.
Flags: blocking1.8b? → blocking1.8b+
This sounds an awful lot like the timing issues in several of the other lock
icon bugs. Will this fall out of those fixes?
Blocks: lockicon
Flags: blocking1.7.6?
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.0.1?
Whiteboard: [sg:fix]
We need to get this one too on the branches.
Flags: blocking1.7.6?
Flags: blocking1.7.6+
Flags: blocking-aviary1.0.1?
Flags: blocking-aviary1.0.1+
Attached patch v1 patchSplinter Review
This bug was caused by the fact that DocLoader was treating 204 and 205 as
successful page loads, and as a result it synthesized a STATE_TRANSFERRING
event for the request, which triggered SecureBrowserUI to update the lock icon
state.

This patch takes the simple route of returning an error code to necko to
indicate that URILoader is not interested in 204 or 205 responses.

We could also make DocLoader check for 204 and 205, but this seemed simpler. 
The only "downside" to this patch is that WebProgressListeners will now see
that we 204 and 205 responses are canceled.  But, I can live with that :)
Attachment #173818 - Flags: superreview?(bzbarsky)
Attachment #173818 - Flags: review?(cbiesinger)
Target Milestone: --- → mozilla1.8beta1
Comment on attachment 173818 [details] [diff] [review]
v1 patch

sr=bzbarsky, but please file a followup bug as we discussed on the docloader,
what things we should synthesize STATE_TRANSFERRING for, etc.
Attachment #173818 - Flags: superreview?(bzbarsky) → superreview+
Attachment #173818 - Flags: review?(cbiesinger) → review+
Attachment #173818 - Flags: approval1.7.6?
Attachment #173818 - Flags: approval-aviary1.0.1?
Attachment #173818 - Flags: approval1.8b?
Comment on attachment 173818 [details] [diff] [review]
v1 patch

a=dveditz for 1.7 and 1.0.1 branches
Attachment #173818 - Flags: approval1.7.6?
Attachment #173818 - Flags: approval1.7.6+
Attachment #173818 - Flags: approval-aviary1.0.1?
Attachment #173818 - Flags: approval-aviary1.0.1+
Comment on attachment 173818 [details] [diff] [review]
v1 patch

a=caillon for 1.8beta
Attachment #173818 - Flags: approval1.8b? → approval1.8b+
fixed-on-trunk, fixed-aviary1.0.1, fixed1.7.6
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Flags: blocking-aviary1.1?
Verified fixed.  With testcase in comment #3, the address bar displays the
current bugzilla url and the lock icon shows the proper security info and cert
for mozilla.org.

Aviary Branch: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5)
Gecko/20050217 Firefox/1.0

M18a/Trunk: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050217

M176 Branch: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050217
Status: RESOLVED → VERIFIED
Group: security
Attachment #187619 - Flags: review?(cbiesinger)
Attachment #187619 - Flags: superreview?(bzbarsky)
Attachment #187619 - Flags: review?(cbiesinger) → review+
Attachment #187619 - Flags: superreview?(bzbarsky) → superreview+
Flags: testcase+
Flags: in-testsuite+ → in-testsuite?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: