sidebar URL can be changed to a different domain

RESOLVED FIXED

Status

()

Firefox
SocialAPI
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: markh, Assigned: mixedpuppy)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Fx16])

(Reporter)

Description

5 years ago
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.
(Reporter)

Comment 1

5 years ago
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.
(Assignee)

Comment 2

5 years ago
(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.
(Reporter)

Comment 3

5 years ago
(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.
(Reporter)

Comment 4

5 years ago
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)
(Assignee)

Comment 5

5 years ago
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.
(Assignee)

Updated

5 years ago
Whiteboard: [ms2]

Updated

5 years ago
Whiteboard: [ms2] → [Fx17]
(Assignee)

Comment 6

5 years ago
lock down to single host for fx16, deal with host whitelist after.
Whiteboard: [Fx17] → [Fx16]
(Assignee)

Updated

5 years ago
Assignee: mhanson → mixedpuppy
(Assignee)

Comment 7

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

leaving open for reference in landing sidebar
(Assignee)

Updated

5 years ago
Blocks: 755136
(Assignee)

Updated

5 years ago
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.