All users were logged out of Bugzilla on October 13th, 2018

Online installation of extensions fails when pref 'network.http.sendRefererHeader' has not the value 2

NEW
Unassigned

Status

14 years ago
3 years ago

People

(Reporter: whimboo, Unassigned)

Tracking

Bug Flags:
blocking-aviary1.0 -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

14 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040831
Firefox/0.9.1+

Trying to install an extension or theme which is linked from a website doesn't
work if the xpi is located on another domain. Try to install the extension
"JavaScript Console Status" from the url specified above. This xpi is located at
http://www.cosmicat.com/. You will get the notice to allow xpi installations
from this website. When you choose 'edit options' the domain of the website is
displayed. If you add this entry you also can't install this extension because
it is located on another domain! You will get the notification again and again
until you allow the origin domain of the xpi.

We shouldn't give rights for installations to the website! Instead the domain of
the xpi location should be added! I don't know if it's a security hole and
someone could use it to install a malicous extension. So I marking this bug as
critical for now!
(Reporter)

Updated

14 years ago
Summary: XPI installations should work on XPI location instead of the website → Allowed domains for xpi installations should work on doman of the xpi instead of the website
(Reporter)

Comment 1

14 years ago
Because of the unknown severity just asking for blocker of PR1 to avoid an
unnecessary patch release.
Flags: blocking-aviary1.0PR?
(Reporter)

Comment 2

14 years ago
Same behavior applies for update.mozilla.org. I'm not able to install any
extensions! Updating the URL.
(Reporter)

Comment 3

14 years ago
Ok, I checked the behaviour more deeply and noticed that installation fails when
we dont send a referer. When the the preference 'network.http.sendRefererHeader'
is disabled you will stay in a loop for editing the white list of allowed websites.

I updated the status for this bug cause it doesn't seems to be critical.
Severity: critical → normal
Flags: blocking-aviary1.0PR?
Summary: Allowed domains for xpi installations should work on doman of the xpi instead of the website → Online installation of extensions fails when pref 'network.http.sendRefererHeader' is set to false

Comment 4

14 years ago
(In reply to comment #3)
> Ok, I checked the behaviour more deeply and noticed that installation fails when
> we dont send a referer. When the the preference 'network.http.sendRefererHeader'
> is disabled you will stay in a loop for editing the white list of allowed
websites.

Note that programs like Norton Internet Security also block the sending of a
referrer as part of their privacy protection.
(Reporter)

Comment 5

14 years ago
I didn't know the internal process but do we really need a referrer? All
processing should be done locally. We have our white list of domains and know
the location within the current window or frame. Why not check this instead of
using a referrer? 
(Reporter)

Comment 6

14 years ago
This hampers a lot of people who have disabled referrers. Asking for blocker of
aviary1.0.
Flags: blocking-aviary1.0?
(Reporter)

Comment 7

14 years ago
I checked that the referrer pref isn't a bool pref. Every installation fails
when the pref hasn't a value of two.
Summary: Online installation of extensions fails when pref 'network.http.sendRefererHeader' is set to false → Online installation of extensions fails when pref 'network.http.sendRefererHeader' has not the value 2

Comment 8

14 years ago
dveditz introduced referrer-checking for XPIs in bug 240552 (see bug 240552
comment 38).  It might be nice to have a separate "internal referrer" field that
could work with FTP, wouldn't get disabled or spoofed, etc.
Not sure we must fix this for 1.0, I'll let others + this bug.

/be
The channel owner could have been such an "internal referrer" mechanism, but
trying to use it that way really messed things up when I tried it. Later jst
rediscovered that same thing when trying something similar while fixing the
frame-spoofing bug.

nsIChannel2?

Comment 11

14 years ago
Is this going to cause problems if we force everyone to use HTTPS for
update.mozilla.org?  (Links from HTTPS doesn't get a referer, although IMO they
should get the hostname without a path as a referer.)
The referrer is used only for link clicks. When a javascript trigger is used we
know exactly who is initiating the install.

Comment 13

14 years ago
*** Bug 259743 has been marked as a duplicate of this bug. ***
Component: Extension/Theme Manager → Installer: XPInstall Engine
Product: Firefox → Browser
Version: unspecified → Trunk

Comment 14

14 years ago
not a common case. I don't think we block on this.
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Assignee: bugs → xpi-engine
QA Contact: bugs
Assignee: xpi-engine → nobody
QA Contact: xpi-engine
(Assignee)

Updated

3 years ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.