we need some kind of visual cue that allows the user to know they are in fact on the site they are logging into. If a provider is spoofed by evil provider who manages to get the user to install them, our current ui provides no indication what domain the sidebar is loaded from, resulting in no way for the user to know whether they are secure or not.
Just to clarify the WONTFIX: we will require SSL for provider URLs, and SSL failures will be fatal, so we shouldn't need to worry about provider spoofing.
What kind of "visual cue" are you envisioning?
Can you please try to explain this to me like I'm a 6 year old? I don't understand this requirement at all. You're prescribing some kind of UI that I can easily start to riff on but to solve a problem that I don't see/understand.
(In reply to Asa Dotzler [:asa] from comment #6) > Can you please try to explain this to me like I'm a 6 year old? I don't > understand this requirement at all. You're prescribing some kind of UI that > I can easily start to riff on but to solve a problem that I don't > see/understand. (I am not on the security team.) If we place a sidebar on a page then that sidebar can be spoofed by malicious websites and users won't know the difference. The malicious sidebar could do things like request user credentials. It's my understanding that the security team would like the sidebar to incorporate some kind of chrome UI (potentially overlapping the toolbars like the doorhanger notifications) so users can have a way to verify the validity of the sidebar. With that being said, there is a fine line between having the extra chrome being too obnoxious while also being visible enough for users to notice and distinguish legitimacy from phishing.
I don't think that's really feasible. Just about any solution I can think of is trivially spoofable. Also, we don't have that for the existing feature of bookmarks opened in sidebars which we've been shipping for years.
I agree, I think the incremental benefit of fixing this bug is being overstated. We're going to need to communicate sidebar best practices to providers (particularly those we choose to include by default), I think Adam filed a bug on that. There's no magical technical solution that will entirely erase this problem.
As this bug current reads, I don't believe that this is something we should invest in and would like to re-resolve this as wontfix. (and I'm still not clear on what threat you're trying to protect users from. What is the user failure you anticipate and the consequences of that failure.)
Heres a simple POC to illustrate this threat: https://people.mozilla.com/~sbennetts/socialapi2739/fake-frame.html There are mitigating factors, as this is only likely to work if the the user/target has: 1) installed the Facebook provider 2) closed the sidebar 3) see content they think is worth sharing on the phishing page 4) dont notice the change in behavior (ie login in the sidebar rather than a new tab) Having said that, I can see users falling for this.
(In reply to Simon Bennetts [:psiinon] from comment #11) > Heres a simple POC to illustrate this threat: > https://people.mozilla.com/~sbennetts/socialapi2739/fake-frame.html > > There are mitigating factors, as this is only likely to work if the the > user/target has: > 1) installed the Facebook provider > 2) closed the sidebar > 3) see content they think is worth sharing on the phishing page > 4) dont notice the change in behavior (ie login in the sidebar rather than a > new tab) > > Having said that, I can see users falling for this. We don't ask users to auth in the sidebar. We auth in the main window where users can see the addressbar.
I realise that, but do they? How are they to know that we havnt changed our policy. Remember we are not talking about the most technical users here.
The incremental risks of spoofing caused by the social API sidebar are real, but they're not large compared to the existing possible spoofing attacks. It's not really possible to reliably detect the presence of the social sidebar from a third party web site, so pulling off this attack in practice would often result in "double sidebars" or other fishy indications that something's not right.
The existing sidebar that is specific to social is pretty identical in nature (css/xul/appearance/etc) to the left sidebars, which also can contain "bookmarked sidebars", which are also installable via APIs that are available to every website (if you're surprised, I was too). Considering that, any spoofability of the sidebars is a general ui issue for firefox, not a socialapi specific issue. I'm going to WONTFIX this from a socialapi perspective, if this issue is really that important, I would suggest a new bug about the general spoofability of all sidebars in firefox.