Closed
Bug 541308
Opened 15 years ago
Closed 13 years ago
random websites can manipulate personas by framing a whitelisted site
Categories
(Firefox :: General, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 542020
People
(Reporter: asa, Unassigned)
References
()
Details
(Whiteboard: [sg:moderate])
Attachments
(2 files, 1 obsolete file)
random websites can manipulate personas Seems like a big problem to me. I was under the assumption that only getpersonas.com or other whitelisted sites could manipulate Firefox's personas but that appears to not be the case. http://lug.wsu.edu/~ben/personal.html
Reporter | ||
Comment 1•15 years ago
|
||
from facebook conversation at http://www.facebook.com/asadotzler?v=feed&story_fbid=301274168011
Comment 2•15 years ago
|
||
I'm sorry, I don't understand from that URL what the problem is. Hovering over any of the personas on that site doesn't show a preview. Clicking on them takes me to the Personas website where I can then install them. This seems INVALID to me; what am I missing?
Reporter | ||
Comment 4•15 years ago
|
||
so probably not a security sensitive bug since the content comes from a trusted site. still, this was kind of shocking to me and others and perhaps it's a behavior we should consider changing.
Group: core-security
Comment 5•15 years ago
|
||
Why was it shocking? Web designers can do many things that are a nuisance for users, at the cost of losing or annoying those users. The behaviour as designed allows sites that are permitted to install add-ons (so, those listed as exceptions in the security prefs) to deliver previews of a persona as well as one-click install without a confirmation prompt. We allow this to happen even when the content is hosted in an iframe because the content is coming from a secure source. (FTR, the firstrun page on mozilla.com relies on this functionality, though that's not why it was designed this way.)
Reporter | ||
Comment 6•15 years ago
|
||
It was shocking because until now, no website could mess with my chrome like that. They could do all kinds of annoying things, but they couldn't hijack my chrome like that.
Thanks Asa. My concern is that even though the previews only work for trusted sites, that it seems trivial to write a script that would cycle through persona previews at a rapid rate or some other incredibly annoying behaviour and post it on forums all over. And as far as I can tell, there doesn't seem to be a way of disabling that. (aside from the drastic step of removing getpersonas.com from your trusted sites.)
Comment 8•15 years ago
|
||
Mike: perhaps you unwhitelisted the getpersonas site? Go to the gallery and see if the mouseover works there, and if not you can change page permissions through the page-info dialog. This page is a scraped version of Mozilla content. I guess not a copyright issue since it's CC-by-SA, but maybe some trademark confusion issue. Regardless, in the middle of the page the personas are in a frame that comes from the whitelisted personas site so it's able to do persona stuff. It's of course completely unclear that content comes from another site so it looks like lug.wsu.edu is doing it. I can see cases where this might be useful (we didn't have to whitelist mozilla.com in order to show off this feature) but it can also be confusing and alarming to users. Should a site abuse this framing there's no (obvious) way for the user to stop it -- even if they discover the site-permission setting they can explicitly block the framing site until they're blue in the face and it'll do no good.
Updated•15 years ago
|
Summary: random websites can manipulate personas → random websites can appear to manipulate personas by framing a whitelisted site
Comment 9•15 years ago
|
||
is there anyway to hide the images in the div? that could make it even more mysterious to a user that mouses around, and give the appearance to the user that something has taken control of the PC. Possibly leading to Your browser has been hacked! click here to download browser cleaner-upper tools...
Comment 10•15 years ago
|
||
I didn't even notice the iframe because it was injected by js. If the js and the persona -both- have to come from getpersonas.com then I'm not quite as concerned. @Chris, yes, I believe that you could hide the frame by overlaying it with an opaque layer and using pointer-events to pass events through: http://hacks.mozilla.org/2009/12/pointer-events-for-html-in-firefox-3-6/
Reporter | ||
Comment 11•15 years ago
|
||
dveditz, this site was set up explicitly to testcase this issue. there should be no concern over trademark, copyright, etc. Ben was trying to show me how a site that wasn't Mozilla's could manipulate Firefox chrome.
Updated•15 years ago
|
OS: Windows 7 → All
Hardware: x86 → All
Comment 12•15 years ago
|
||
Is there any real harm done? No, the effect goes away when the user leaves the page. Will the typical user understand that and say "OK, annoying site"? I don't think so, changing the chrome is clearly reaching outside the content window and raises doubts about what other evils the page could do. Pushy sites could use this to "brand" your browser while you're on their site -- all they need is to submit a persona that's not too outrageous. Griefers could try to slip some offensive images in there, or annoy the hell out of you with quick changes.
Comment 13•15 years ago
|
||
While I agree in general that this doesn't seem like a big issue, I also don't see any significant reason here why the current behavior can't be changed to just avoid this issue altogether.
Comment 15•15 years ago
|
||
(In reply to comment #5) > Why was it shocking? Web designers can do many things that are a nuisance for > users, at the cost of losing or annoying those users. Yes, but where those things are not limited to the content area, we very much tend to consider them bugs. I think this is unpleasantly surprising *browser* behaviour for users, not just unpleasant site behaviour. We should look for ways to mitigate it, possibly just by frame-busting on the getpersonas site.
Comment 16•15 years ago
|
||
cc'ing webdev I'm getting swayed by the arguments, I think. Framebusting sounds like a good solution.
Comment 17•15 years ago
|
||
So, what about framebusting but with an exemption for www.mozilla.com (and various staging sites) so we can continue to use the iframe. Is that possible?
Comment 18•15 years ago
|
||
I agree that while this behaviour was basically intentional (at least, inasmuch as we knew an iframe approach would work for the firstrun page) and while I can't see a real security risk to it (or we would have ruled it out altogether), it's still pretty irritating, and would be nice to see it mitigated. We shouldn't rule out client side changes if need be, but give that there are only two sites trusted to do this (AMO and getpersonas), something web-side like framebusting might well be enough. As reed says, it would be particularly nice if this could be done in a way that didn't hurt the firstrun experience (which people seem to love). Adding getpersonas/AMO folk.
Comment 19•15 years ago
|
||
Wouldn't have to be frame-busting, the site could just not send the persona-changing events unless it's got proof that it's safe to do so, e.g. self==top OR document.referrer.match("^https?://([^/]*)")[1] == "www.mozilla.com". Could also go HTML5 and try postMessage() since we get an origin out of that, but that seems needlessly complex.
Comment 20•15 years ago
|
||
I agree it's annoying and could be seen as some sort of security problem by an average user. Pretty sure we could do some detection via JS, but honestly this was going to be a 'feature' to allow users to share their personas on their own websites. Wondering if there's any other options.
Comment 21•15 years ago
|
||
(In reply to comment #20) > I agree it's annoying and could be seen as some sort of security problem by an > average user. Pretty sure we could do some detection via JS, but honestly this > was going to be a 'feature' to allow users to share their personas on their own > websites. Wondering if there's any other options. Yeah, for me I think the idea of making getpersonas a privileged path, like AMO is, makes sense and I don't think we hurt personas as a feature by saying that if you host your persona elsewhere, you don't get previews unless the user changes your site's permissions. It's not like we're talking about making it impossible for third parties to host or install - the experience is just more irritating because that's our defense against nuisance. A hypothetical otherpersonas.com that was hosting a large number of them would have to convince users to extend them similar trust, after which things would work identically. That being said, then, I think dveditz's suggestion has merit, +/- the unreliability of referrer.
Comment 22•15 years ago
|
||
FWIW, using the latest trunk build and hovering over the images on the "fake" website does change my chrome but on getpersonas.com it does. Using 3.6, both sites change the chrome.
Comment 23•15 years ago
|
||
I don't think postMessage should be hard here, and it gives a useful basis for an API richer than <script src=> or <iframe src=> to meet the other-site needs sketched above by Ryan. That we reliably get the origin out of it means that the personas site can even include site identity in a prompt for installation, etc.
Comment 24•15 years ago
|
||
(In reply to comment #23) > I don't think postMessage should be hard here, and it gives a useful basis for > an API richer than <script src=> or <iframe src=> to meet the other-site needs > sketched above by Ryan. That we reliably get the origin out of it means that > the personas site can even include site identity in a prompt for installation, > etc. You're thinking that if self != top we disable previews unless we get a postMessage that says something like "here's my ID, check your in-house whitelist and decide whether or not to enable previews?" That would be downright swell, I rather suspect, and does give us forward flexibility, too.
Comment 26•15 years ago
|
||
(In reply to comment #22) > FWIW, using the latest trunk build and hovering over the images on the "fake" > website does change my chrome but on getpersonas.com it does. Using 3.6, both > sites change the chrome. Same thing with a new profile on trunk. So maybe this bug was somehow fixed unknowingly on the trunk in some other bug?
Reporter | ||
Comment 27•15 years ago
|
||
another nice testcase just hit digg: "Persona-jacking" http://dl.dropbox.com/u/3011522/personas.html
Comment 28•15 years ago
|
||
another example of the suggested attack in comment 5 that spoofs user into thinking something is wrong with their browser and solicits a fix. the result is general confusion at best, and fear that you need to be saved from a virus at worse.
Attachment #422924 -
Attachment is obsolete: true
Comment 29•15 years ago
|
||
the alignment is a bit funky, but with more playing around it could get more precise.
Comment 30•15 years ago
|
||
Can someone (perhaps Johnath) file specific, separate bugs for the implementation of whatever solution was deemed best (postMessage?) for both getpersonas.com and AMO?
Comment 31•15 years ago
|
||
(In reply to comment #30) > Can someone (perhaps Johnath) file specific, separate bugs for the > implementation of whatever solution was deemed best (postMessage?) for both > getpersonas.com and AMO? Filed bug 542020 (Personas & Firstrun pages) and bug 542022 (AMO). AMO can probably roll this fix whenever because I don't think they are currently being iframed anywhere that we support (right?) but the personas fix has to work in tandem with a fix to our firstrun pages and anywhere else that does that kind of framing.
Comment 32•15 years ago
|
||
so all the examples of this use the demo iframe at http://www.getpersonas.com/en-US/external/mozilla/firstrun.php has anyone played with putting individual personas in an iframe? that would be a short cut to the spoofing exploit, and we should make sure we defend against that as well.
Comment 33•15 years ago
|
||
@chris: About what you'd expect. You could get a hell of a lot more sophisticated with this if you had the motivation to spend more than a few minutes on it. http://lug.wsu.edu/~ben/personaJack.html http://lug.wsu.edu/~ben/personaJackExtra.html
Comment 34•15 years ago
|
||
(In reply to comment #32) > has anyone played with putting individual personas in an iframe? Chris: see my attachment 422935 [details] from comment 12. I guess at this point keeping it hidden is pointless.
Updated•15 years ago
|
Attachment #422935 -
Attachment is private: false
Comment 35•15 years ago
|
||
personas changed the site, breaking my PoC: the anchor doesn't work when the persona page is inside a frame. See http://www.getpersonas.com/en-US/persona/65437#maincontent vs data:text/html,<iframe src="http://www.getpersonas.com/en-US/persona/65437#maincontent"></iframe>
Summary: random websites can appear to manipulate personas by framing a whitelisted site → random websites can manipulate personas by framing a whitelisted site
Updated•15 years ago
|
Group: core-security
Comment 36•15 years ago
|
||
We were talking about this last week. I think this is fairly security critical, even if you can't inject code. Text can be overlayed over the UI, pretending a site is safe and such.
Group: core-security
Comment 37•15 years ago
|
||
For the record, I would prefer to hide this bug for further discussion but it seems a decision was made not to, so I will not hide it.
Comment 38•15 years ago
|
||
Marking sg:moderate due to potential for spoofing of browser security indicators. For example, we already have at least one persona submitted for a bank identity (http://www.getpersonas.com/en-US/persona/82571 corresponds to www.erstebank.at). Great fodder for phishing.
Whiteboard: [sg:moderate]
Comment 39•15 years ago
|
||
Its a bit far fetched but lucas and I were also talking about the possibility of a green bar-ish, or blue bar-ish, and/or larry-ish looking persona. it would be hard to get it looking exactly right but with enough work it might be close enough to fool a few people that they were on a secure connection.
Comment 40•15 years ago
|
||
First, [sg:moderate] seems pretty high to me, given the descriptions of security rankings as listed here https://wiki.mozilla.org/Security_Severity_Ratings I would expect this to be [sg:low]. Second, with the changes made to the by-default whitelisted sites, this now becomes a two stage social attack, correct? Just want to make sure everyone's aware that it's not as easy as dropping an iframe into arbitrary HTML. The attacker must now convince the user to add some site to the software whitelist. Not impossible, but much tougher with the default preferences we have in Firefox.
Comment 41•15 years ago
|
||
(In reply to comment #40) > First, [sg:moderate] seems pretty high to me, given the descriptions of > security rankings as listed here > https://wiki.mozilla.org/Security_Severity_Ratings I would expect this to be > [sg:low]. Oh, sorry, I see how it could be considered [sg:high] if one could take over the entire URL bar. You can't, really, with the way Personas work today, but if the way to represent that is to hedge and say [sg:moderate] then OK. I would think we'd want [sg:high?] to represent the potential, though. Obviously my understanding of how these rankings work is shakey.
Comment 42•13 years ago
|
||
From a quick skim, I can't reproduce this with the URL in this bug. Did we fix this, or did something else just make it stop working as "expected"?
Comment 43•13 years ago
|
||
(In reply to Justin Dolske [:Dolske] from comment #42) > From a quick skim, I can't reproduce this with the URL in this bug. Did we > fix this, or did something else just make it stop working as "expected"? Yep, fixed via bug 542020.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•