Closed Bug 766622 Opened 12 years ago Closed 10 years ago

make sidebar visually distinct from web content to reduce possibility of spoofing sidebar content

Categories

(Firefox Graveyard :: SocialAPI, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: mixedpuppy, Unassigned)

References

Details

(Keywords: uiwanted)

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.
Blocks: 733414
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.
Whiteboard: [ms1][needs-ux]
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
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
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
What kind of "visual cue" are you envisioning?
OS: Mac OS X → All
Hardware: x86 → All
Whiteboard: [ms1][needs-ux] → [needs-ux]
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?
Blocks: 755136
No longer blocks: 733414
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.
Summary: visual cue for security of sidebar → make sidebar visually distinct from web content to reduce possibility of spoofing sidebar content
(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.
Keywords: uiwanted
Whiteboard: [needs-ux]
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.
Status: REOPENED → RESOLVED
Closed: 12 years ago10 years ago
Resolution: --- → WONTFIX
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.