276720 - wrong behavior with "http/1.1 204 no content"

Status: VERIFIED FIXED

(Core :: Security, defect)

Description

[Mathieu Deaudelin-Lemay (previous account)]

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.

Comment 1

[Mathieu Deaudelin-Lemay (previous account)]

Attachment: Screenshot of this bug in Firefox 1.0

Comment 2

[Mathieu Deaudelin-Lemay (previous account)]

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).

Comment 3

[Mathieu Deaudelin-Lemay (previous account)]

Attachment: Test page for this bug

This replaces the screenshot i had posted. sorry for all this spam.

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

fixed with bug 268483 maybe?

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

hm, obviously not - still seeing this in a trunk build (linux)

Comment 6

[Daniel Veditz [:dveditz]]

-> Darin

Comment 7

[Boris Zbarsky [:bzbarsky]]

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.

Comment 8

[Darin Fisher]

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).

Comment 9

[Darin Fisher]

forget i mentioned paypal... the fact that this can be used to spoof
passport.com sounds plenty serious to me.

Comment 10

[Daniel Veditz [:dveditz]]

This sounds an awful lot like the timing issues in several of the other lock
icon bugs. Will this fall out of those fixes?

Comment 11

[Christopher Aillon (sabbatical, not receiving bugmail)]

We need to get this one too on the branches.

Comment 12

[Darin Fisher]

Attachment: v1 patch

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 :)

Comment 13

[Boris Zbarsky [:bzbarsky]]

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.

Comment 14

[Daniel Veditz [:dveditz]]

Comment on attachment 173818 [details] [diff] [review]
v1 patch

a=dveditz for 1.7 and 1.0.1 branches

Comment 15

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 173818 [details] [diff] [review]
v1 patch

a=caillon for 1.8beta

Comment 16

[Darin Fisher]

fixed-on-trunk, fixed-aviary1.0.1, fixed1.7.6

Comment 17

[Jay Patel [:jay]]

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

Comment 18

[Nian Liu(n/a in a long time)]

Attachment: patch for 1.4 branch