523249 - Link redirection service for mozilla sites

Status: VERIFIED FIXED

(addons.mozilla.org Graveyard :: Administration, defect, P1)

Description

[Justin Scott [:fligtar]]

Mozilla sites on the Firefox add-ons whitelist (AMO, getpersonas.com) need to be able to link to user-entered URLs without fear of a drive-by add-on install. We currently do this by not auto-linking any user-entered URLs in most places, but an upcoming AMO will significantly increase the number and visibility of several user-entered URLs.

We need a non-whitelisted redirector service that can send users to the requested URL without that danger.

Proposal:
* A standalone script is hosted at a non-official looking Mozilla site, such as outgoing.mozilla.org or something even less trusted like mozredirect.net. (This is so if the yellow bar does come up with "mozredirect.net wants to install an add-on" someone would not click yes just because it has mozilla.org in it)

* This script would take the URL to be forwarded to and a hash, so that not anyone could use the redirector.

* The hash would be generated from the URL + a secret salt that is shared across Mozilla sites that use the service (AMO and getpersonas)

The sites that use this service would then replace all links with this service, and optionally fake the statusbar text with JS.

This bug blocks a number of other bugs, including some not yet filed for the upcoming AMO 5.3 release.

Putting this bug in AMO as we will likely take responsibility for writing the script, although IT's input and help with setting up the non-AMO domain will be needed.

Comment 1

[Jeff Balogh (:jbalogh)]

Firefox will follow HTTP redirects from a whitelisted site and apply permissions to whatever is at the endpoint, even if the final location is not on the whitelist.  I presume that using a <meta> redirect will not have this effect, but I haven't tested it yet.

The hash doesn't provide that much security since it's out in the open as soon as someone enters that URL on one of our sites.  But it does prevent a completely open relay since there's a manual link creation step in the middle.

I would prefer a redirect domain that doesn't contain "mozilla" at all.  mozredirect.net looks like an impostor site and something with mozilla gives too much credibility.

Here's an implementation: http://github.com/jbalogh/moonshoes

Comment 2

[Wil Clouser [:clouserw]]

If this is in 5.3 we need the domain that is hosting this ASAP.

Comment 3

[matthew zeier [:mrz]]

Can you work with something under mozilla.net?

Otherwise, please suggest the domain.

Comment 4

[Justin Scott [:fligtar]]

Assigning to Jeff. We'll decide on the domain in tomorrow's weekly AMO meeting and file an IT bug for it if it requires registration.

Comment 5

[Jeff Balogh (:jbalogh)]

(In reply to comment #4)
> Assigning to Jeff. We'll decide on the domain in tomorrow's weekly AMO meeting
> and file an IT bug for it if it requires registration.

What was the decision for the domain?  And what are we doing (if anything) for the interstitial page?  There was talk of having words on it, which means we'll have to get L10n involved.

Comment 6

[Justin Scott [:fligtar]]

Attachment: mockup

As discussed in last week's AMO meeting, we'd like to use outgoing.mozilla.org, but have text as shown in the above mockup. We have to use meta redirects in order for the whitelist bar to drop down if someone were to link directly to a xpi/jar/download.

For almost all cases, the text will only be on the screen for a split second before redirecting to the destination. However, if the destination is a .xpi, .jar, or other download file, the text will still be visible at the bottom of the screen and will encourage users to use caution and report the installation to us, as it's against our policy to link directly to a file.

This is more of an AMO-specific implementation detail, but we'll also want to append a special parameter for metrics to be able to count the number of self-hosted add-on clicks.

Comment 7

[Justin Scott [:fligtar]]

Oh, and the report link will go to https://addons.mozilla.org/developers/docs/policies/contact

Comment 8

[Fred Wenzel [:wenzel]]

Quick question, the "install this" box in the mock-up is the add-on installer UI, and not part of the redirector, or is it?

Comment 9

[Wil Clouser [:clouserw]]

(In reply to comment #8)
> Quick question, the "install this" box in the mock-up is the add-on installer
> UI, and not part of the redirector, or is it?

add-on installer UI, not part of this

Comment 10

[Jeff Balogh (:jbalogh)]

fligtar: what do we want to say when the hash is invalid?

Comment 11

[Fred Wenzel [:wenzel]]

(In reply to comment #10)
> fligtar: what do we want to say when the hash is invalid?

OMGWTFBBQ?

Comment 12

[Justin Scott [:fligtar]]

(In reply to comment #10)
> fligtar: what do we want to say when the hash is invalid?

Invalid address.

Comment 13

[Jeff Balogh (:jbalogh)]

Attachment: link redirector based on http://github.com/jbalogh/moonshoes

Comment 14

[Jeff Balogh (:jbalogh)]

Attachment: link redirector based on http://github.com/jbalogh/moonshoes

passing in the safe version of the url

Comment 15

[Wil Clouser [:clouserw]]

Comment on attachment 410037 [details] [diff] [review]
link redirector based on http://github.com/jbalogh/moonshoes

Please make config.php a -dist and use a full doctype

Comment 16

[Ryan Doherty (:rdoherty)]

(In reply to comment #15)
> (From update of attachment 410037 [details] [diff] [review])
> Please make config.php a -dist and use a full doctype

<!DOCTYPE html> is the HTML5 doctype, so we're good here.

Comment 17

[Jeff Balogh (:jbalogh)]

r55002

Comment 18

[Stephen Donner [:stephend] Not actively reading bugmail]

Can someone please provide a testcase for this?  Thanks!

Comment 19

[Wil Clouser [:clouserw]]

This works:

http://outgoing.mozilla.org/v1/0a467c4f0dfd6e9a726b92a27055a57215057653/http%3A//fireftp.mozdev.org

This doesn't:
http://outgoing.mozilla.org/v1/0a467c4f0dfd6e9asdf57215057653/http%3A//fireftp.mozdev.org

Comment 20

[Fred Wenzel [:wenzel]]

If we want people to see the redirection page (does it contain a warning or so?) then it redirects too fast. I can barely see the page title before the target page loads.

Comment 21

[Jeff Balogh (:jbalogh)]

(In reply to comment #20)
> If we want people to see the redirection page (does it contain a warning or
> so?) then it redirects too fast. I can barely see the page title before the
> target page loads.

In general, we don't want people to see that page.  There's actually a two second pause before we make the page content (a warning) visible.

If someone is linking to an xpi or other downloadable file, the user will stay on the redirection page and see the warning pop up.

Comment 22

[Fred Wenzel [:wenzel]]

Ah, that makes sense. Carry on then, there's nothing to see here :)

Comment 23

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED, as best I understand it.

Comment 24

[Jesse Ruderman]

I would have preferred a fix in Firefox (e.g. bug 358266) rather than this server-side hackaround.

Comment 25

[Justin Dolske [:Dolske]]

unst unst

Comment 26

[Wil Clouser [:clouserw]]

(In reply to comment #24)
> I would have preferred a fix in Firefox (e.g. bug 358266) rather than this
> server-side hackaround.

This doesn't block a fix in firefox.

Comment 27

[Justin Scott [:fligtar]]

(In reply to comment #24)
> I would have preferred a fix in Firefox (e.g. bug 358266) rather than this
> server-side hackaround.

us too! My Firefox bugs often get WONTFIXed (recent xpinstall whitelist example: bug 522522) so we usually fix problems with the assumption we have to do it ourselves and then if we find out otherwise we can make changes.