Closed Bug 1174493 Opened 9 years ago Closed 6 years ago

Page doesn't change when no-content code 204 is received for new location

Categories

(Firefox :: Address Bar, defect)

41 Branch
defect
Not set
normal

Tracking

()

RESOLVED INACTIVE

People

(Reporter: raysatiro, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:41.0) Gecko/20100101 Firefox/41.0
Build ID: 20150613030206

Steps to reproduce:

tl;dr I think this is unlikely to have a security impact but I've marked it that way as a precaution.

Go to any website eg http://example.com/
Now in that tab go to http://httpstat.us/204 which will generate a 204 no-content response.



Actual results:

e10s the location url will stay as http://example.com/
non-e10s (Tested Nightly, Aurora, 31ESR) the location bar url will change to http://httpstat.us/204
In both cases the content stays as the content of example.com

Redirects seem to have the same location bar behavior as e10s. I tested in 31ESR with several different types of redirect and in those cases the url that appears in the location bar isn't replaced with the no-content url.


Expected results:

I'd expect in any case if you go to a different url that returns no content that there be something that says "This page has no content" or a blank page and not keep the content from the old page.

Also, it looks like there is a similar situation with reset-content 205.

Since redirects don't change the url I don't see how this could be exploited unless site-rogue could convince user to manually put into their location bar a url of site-impersonate and that url returned a 204/205. I'm marking this as security though because I really don't know how feasible that is or whether there's something I'm missing.
This is essentially like bug 802026 and bug 521461 except the security UI does not get updated, so at least we don't pretend the new page is secure - but the fact that we show the different URL without updating the content shown is very strange.

Gavin, you fixed bug 802026, do you know why we're not updating the URL / content ?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(gavin.sharp)
If a page navigates itself to a 204 page we don't update the URL bar. There's no content change, and no location bar change -- can't use this for spoofing.  If the user types the 204 URL then "nothing happens" and some sort of response would be nice. The user _is_ left with the old content but the new URL showing which could be confusing, but since it's self-inflicted it doesn't need to be hidden as a security bug. If the user hits ESC then the location bar URL reverts to the correct value.
Group: core-security
Component: Untriaged → Location Bar
Sorry, I don't have any useful recollection here!
Flags: needinfo?(gavin.sharp)
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INACTIVE

This breaks session restore: after closing and reopening Firefox, tabs with 204 responses (opened by middle-clicking on links or entering the URL manually) will show up empty, with no address, like a new tab just opened.

(In reply to Martin F. from comment #5)

This breaks session restore: after closing and reopening Firefox, tabs with 204 responses (opened by middle-clicking on links or entering the URL manually) will show up empty, with no address, like a new tab just opened.

Please file a new bug.

You need to log in before you can comment on or make changes to this bug.