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

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Installer: XPInstall Engine, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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!

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Because of the unknown severity just asking for blocker of PR1 to avoid an
unnecessary patch release.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Same behavior applies for update.mozilla.org. I'm not able to install any
extensions! Updating the URL.

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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.

Comment 4

[Patrick]

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

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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? 

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2]]

This hampers a lot of people who have disabled referrers. Asking for blocker of
aviary1.0.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I checked that the referrer pref isn't a bool pref. Every installation fails
when the pref hasn't a value of two.

Comment 8

[Jesse Ruderman]

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.

Comment 9

[Brendan Eich [:brendan]]

Not sure we must fix this for 1.0, I'll let others + this bug.

/be

Comment 10

[Daniel Veditz [:dveditz]]

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

[Jesse Ruderman]

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

Comment 12

[Daniel Veditz [:dveditz]]

The referrer is used only for link clicks. When a javascript trigger is used we
know exactly who is initiating the install.

Comment 13

[Lachlan Hunt]

*** Bug 259743 has been marked as a duplicate of this bug. ***

Comment 14

[Asa Dotzler [:asa]]

not a common case. I don't think we block on this.