764241 - sidebar URL can be changed to a different domain

Status: RESOLVED FIXED

(Firefox Graveyard :: SocialAPI, defect)

Description

[Mark Hammond [:markh] [:mhammond]]

If the content loaded into a sidebar does, eg, window.location.href = "http://www.google.com", then the sidebar URL changes to google.  There is no indication that the origin has changed and no way to navigate back to the sidebar domain.  I expect the same thing would happen if a redirect was followed off domain.

IMO it should be impossible for the sidebar to navigate to a different origin, but our policy on this isn't clear.

This seems like an unintended consequence of change 0fdbbc841bd148e52cade2e13d1b3c46d557c7fc - that change should theoretically stop moving off domain for clicks on simple <a href=...> elements but doesn't prevent other cases.

Shane believes this is a non-issue, but I'm capturing it here as it seems the implementation doesn't match our intent.  If we can confirm our intent on this, we should at least capture it in a test - if the current impl matches our intent, then a test should be created that demonstrates it.  If the current impl does not match our intent, then a "known failure" test should be created.

Assigning to Mike for comment/decree.

Comment 1

[Mark Hammond [:markh] [:mhammond]]

hrm - this could also be an "attack" vector - the code on the unrelated domain probably has access to navigator.mozSocial, so it could, eg, get a reference to the worker and send it messages.  The workers tend to trust the other side of the port (and indeed it is impossible for them to work out what domain is making the request), so depending on the implementation of the worker, there might be "secrets" that could be stolen.

Comment 2

[Shane Caraveo (:mixedpuppy)]

(In reply to Mark Hammond (:markh) from comment #1)
> hrm - this could also be an "attack" vector - the code on the unrelated
> domain probably has access to navigator.mozSocial, so it could, eg, get a
> reference to the worker and send it messages.  The workers tend to trust the
> other side of the port (and indeed it is impossible for them to work out
> what domain is making the request), so depending on the implementation of
> the worker, there might be "secrets" that could be stolen.

We should have a separate bug on that, it can be solved by checking the origin of the sidebar iframe in the implementation of the APIs in provider.js.  This should be done regardless.

Comment 3

[Mark Hammond [:markh] [:mhammond]]

(In reply to Shane Caraveo (:mixedpuppy) from comment #2)
> We should have a separate bug on that, it can be solved by checking the
> origin of the sidebar iframe in the implementation of the APIs in
> provider.js.  This should be done regardless.

Yeah - "defense in depth" means it should be done, I agree.  However, having something in the sidebar that has no access to the sidebar API seems like a bad state to allow in the first-place - if a URL has no access to the sidebar API then it should not be in the sidebar, as it can't do anything we expect of things in the sidebar.

Comment 4

[Mark Hammond [:markh] [:mhammond]]

Opened bug 764259 to record that we should perform the same-origin test when exposing the mozSocial API regardless of the outcome if this discussion (and FWIW, we *never* had a same-origin check implemented for a "social window" but do expose mozSocial to that regardless of the actual origin)

Comment 5

[Shane Caraveo (:mixedpuppy)]

The use-case is both google and twitter use different domains for auth, including use of redirects to check auth.  We could pattern match to *.provider.com, but that would be bad for providers on services like wordpress.  To some extent, the provider needs to be responsible for a well designed social app.

Comment 6

[Shane Caraveo (:mixedpuppy)]

lock down to single host for fx16, deal with host whitelist after.

Comment 7

[Shane Caraveo (:mixedpuppy)]

fixed in addon, https://github.com/mozilla/socialapi-dev/commit/5619825fa072910466d64bda6a10cbc7303daf5e

leaving open for reference in landing sidebar