I believe the real problem lies in the fact that Flash can actually put things in your clipboard. There should be a security configuration in Flash that makes this clipboard "feature" disabled by default, or at least it should alert the user when the new clipboard content contains malicious code.
Another thing that Facebook can do, is detect Wall-spamming and require the user to confirm that (s)he really wants to spam all his/her friends.
But at that point, you're already working with a user that's fallen victim to social engineering. The script could likely find a way to present the captchas that would similarly fool the user into completing them.
They could just tell the user that the captcha is part of the "security check" the user must do to see if they're in the 2% or whatever. Users will do almost anything if you instruct them well enough.
Agreed that it's unfortunate that flash can write to your clipboard. The only place I've seen that used legitimately is on bit.ly so they can copy the shortened link to your clipboard. Even there, I usually end up confused about what happened and manually copy it anyway.
As far as things we could do at Facebook, we definitely work to detect wall spamming. We end up blocking this kind of spam a lot the time, but there's always room for improvement.
How about running the facebook javascript in a sandbox? Such as proxying the document.createElement and document.getElements* methods for the initial script while breaking it for everything else?
Being able to put things on the clipboard programmatically is a really useful feature. It's actually quite sad that you need flash to do this reliably.
Disabling javascript: urls in the address bar seems like a much better way to mitigate this problem.
While I agree being able to access the clipboard without flash would be very useful, I don't think disabling javascript URLs are a good idea either... A lot of very interesting and useful things can be done with bookmarklets. I suppose given the tradeoffs I'd choose clipboard access over bookmarklets though.
You're not disabling bookmarklets by preventing people from copy/pasting javascript into their address bar. Bookmarklets still work they just can't be executed directly from the address bar.
1. Drag this icon to your favorites bar.
2. Click it.
Might not have the same turnover as the paste-trick but will definitely catch at least 50% of those the other method does. Though IE will warn the user that this is dangerous in step 1 but other browsers doesn't.
Bookmarklets are good but the security model is very fragile. A new concept of widgets has to be introduced in browsers. Kindof like IE8's "web-snippets" but with more power and some sandboxed interface between the widget and the current website. For power users and trusted widgets you should be able to disable the barriers completely to get the same functionality as today, but as opposed to today, this should require a user warning at least on bookmarklet install.
If you nail down clipboard access then it'll just turn into 'drag and drop this to your address bar'. If you nail that down, well, I'm stumped just now, but there's no doubt a few more ways to trigger it.
I think the blame lies with the address bar. If you think about it, it's a bit like having a magic key sequence on your car radio that drops you into the engine management system debugger.
Javascript can put things in your clipboard as well. Well, to clarify.. it's Microsoft's extension to javascript. Unfortunately supported by both Chrome and Firefox. Two of the most popular "alternative" browsers. I think that Safari anad Opera are clean when it comes to this "flaw" (which others call feature of course).
Why flaw you ask? It can edit your clipboard content on "copy" and "paste" action. So you just select text, press ctrl+c and end up with some malicious link in your clipboard.
There are two different things: one is modifying the clipboard from JavaScript. IE used to be able to do that, I don't know if it's still the case. I'd be very surprised if Chrome allowed that…
The second thing is modifying the selection through JavaScript which is indeed possible. However, removing that ability doesn't really solve your problem because you could imagine having white small text embedded wherever you select which would end up in your clipboard without your knowledge.
Quick question, is there any difference between running code in the browser bar vs. running it in the Chrome console? If there isn't, Chrome should just disable this behavior. I don't think I've ever run code in the browser bar vs. the console because I usually have the console open or it's very easy to get to.
I bet most users would smell something fishy if they had to use something like the console to see a video. "Going to a website," even if it's a JS snippet, not a website, is something people are used to. Looking at developer tools, even if it's asking an end user to just see if there was an error, still feels very strange to them.
I'm not 100% sure, but I think the chrome console is essentially the same, but you needn't prepend with javascript: and it has like autocompletion and history and a bunch of other things. Not sure why anyone would legitimately use the address bar for js.
The real question here is why is facebook embedding an untrusted widget. They should whitelist youtube, vimeo and all the major content providers and this issue is effectively gone.
I'm real curious about the url facebook is embedding. If it's an iframe, how does facebook tells that it should be embedded?
At least in 2009, you had to ask Facebook to be whitelisted to be able to see your (the developer's) Flash loaded directly in the timeline. I'm surprised they changed that…
They had a form where you would give your domain name, what you were doing, etc. And they took forever to get back to me when I did that.
> The real question here is why is facebook embedding an untrusted widget.
1. That's not really the question, at all. The attack works fine w/o flash. Flash just helps reduce friction. I'm pretty certain we've seen versions of the attack that don't use flash.
2. Given #1, it doesn't solve the problem, and it creates a new one. See the other response you received.
I'm not sure it might work without flash, there's no way to copy and paste, at least aside from IE[1].
What I'm arguing is the fact that the widget is embedded. Without it, at least one crucial step will be added (switch back to the previous tab), making the scam way less effective.
We've seen the same attack on a 3rd party site that pops up a facebook window that's minimized such that all you can see is the address bar, and has you paste into there. Perhaps a lower conversion rate, but still effective.
This type of attack has been possible for years, but wasn't really replicating until the advent of social networking. Here is the bug I filed with Mozilla the first time I saw this type of attack in the wild: https://bugzilla.mozilla.org/show_bug.cgi?id=527530
There is a lot of interesting discussion in the thread, and Brendan Eich shows up to throw up his two cents in as well.
32 comments
[ 3.2 ms ] story [ 63.8 ms ] threadAnother thing that Facebook can do, is detect Wall-spamming and require the user to confirm that (s)he really wants to spam all his/her friends.
The XSS code could just be modified to automatically confirm its actions.
The only real way to eradicate this problem is what he is already trying to do: educate the users.
As far as things we could do at Facebook, we definitely work to detect wall spamming. We end up blocking this kind of spam a lot the time, but there's always room for improvement.
Put another way, how do we determine if the caller of some of our js is malicious or is us?
Disabling javascript: urls in the address bar seems like a much better way to mitigate this problem.
1. Drag this icon to your favorites bar. 2. Click it.
Might not have the same turnover as the paste-trick but will definitely catch at least 50% of those the other method does. Though IE will warn the user that this is dangerous in step 1 but other browsers doesn't.
Bookmarklets are good but the security model is very fragile. A new concept of widgets has to be introduced in browsers. Kindof like IE8's "web-snippets" but with more power and some sandboxed interface between the widget and the current website. For power users and trusted widgets you should be able to disable the barriers completely to get the same functionality as today, but as opposed to today, this should require a user warning at least on bookmarklet install.
I think the blame lies with the address bar. If you think about it, it's a bit like having a magic key sequence on your car radio that drops you into the engine management system debugger.
Why flaw you ask? It can edit your clipboard content on "copy" and "paste" action. So you just select text, press ctrl+c and end up with some malicious link in your clipboard.
The second thing is modifying the selection through JavaScript which is indeed possible. However, removing that ability doesn't really solve your problem because you could imagine having white small text embedded wherever you select which would end up in your clipboard without your knowledge.
I bet most users would smell something fishy if they had to use something like the console to see a video. "Going to a website," even if it's a JS snippet, not a website, is something people are used to. Looking at developer tools, even if it's asking an end user to just see if there was an error, still feels very strange to them.
Bookmarklets, like http://kathack.com/.
I'm real curious about the url facebook is embedding. If it's an iframe, how does facebook tells that it should be embedded?
They had a form where you would give your domain name, what you were doing, etc. And they took forever to get back to me when I did that.
1. That's not really the question, at all. The attack works fine w/o flash. Flash just helps reduce friction. I'm pretty certain we've seen versions of the attack that don't use flash.
2. Given #1, it doesn't solve the problem, and it creates a new one. See the other response you received.
1: http://stackoverflow.com/questions/400212/how-to-copy-to-cli... (yeah, it's kinda old, but just check google docs--even in chrome, there's no way to copy something with the menu)
There is a lot of interesting discussion in the thread, and Brendan Eich shows up to throw up his two cents in as well.
Also, here is my blog post discussing an attack scenario: http://www.nathanhammond.com/social-engineering-issue-with-j...