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.

We discussed a few details of how this should work. The cue must: Not be emulatable by Javascript/frames: it must be visually distinct from anything that can be created by content. In practice, this could mean having the window descend below or up into the browser chrome would be the most obvious. We discussed having the User Interface design team put some thought into this. As a related topic, we also discussed needing a visual cue for when the Social frame is in "developer mode," which is inherently "unsafe" compared to the normal user mode. This should also be in Chrome to prevent it being emulated by content.

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.

Reopening this - The purpose of using chrome as a visual cue is to make the Social API provider content are be visually distinct from what can be emulated by javascript, flash, etc. The documentation from the meeting where Simon and I discussed this with the Social Integration/SocialAPI team is in #9 in the SecReview docs on the wiki - https://wiki.mozilla.org/Security/Reviews/SocialAPI Requiring SSL addresses a different threat, "4 Built-in provider functionality could be hijacked" from the wiki, not #9. #9 is reproduced below: 9 Phishing threat from spoofing the social browser UX Threat The user may infer a greater degree of trust from social network providers. This could be abused for phishing attacks. How would this work? If an attacker can synthesize a UI that looks like the social service provider, they could drive user behavior - e.g. create a "sidebar" element that looks like chrome in order to steal to a Facebook login. Attack surface through Notification API? Proposed Remediation Visual cue, also visual cue for developer mode Education efforts with providers to never present login bars in sidebar and user education that user will never be asked for logins within sidebar Specify that providers should never ask for login credentials within sidebar. If they choose to do this, they are aware of a very difficult phishing problem. Agreed Path Forward Produce a strongly worded guidance document Make an effort to develop a visual cue, soon. bug 766622

What kind of "visual cue" are you envisioning?

The goal is "The purpose of using chrome as a visual cue is to make the Social API provider content are be visually distinct from what can be emulated by javascript, flash, etc." It's one of the most serious concerns we have for a SocialAPI-lookalike webpage being used for phishing. One thing we discussed was having the socialapi frame being distinct such as going up into the url bar, or descending from the browser. I know this is non-trivial. I don't really care how it looks - it just needs to be something that can't be spoofed by js, flash, etc. but UX design is not my area of expertise. During the initial Secreview, we were told that the UX team would be engaged. Did anyone ever get pulled in? Is there any way I can facilitate that?

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.