Self-XSS attack explained | Hacker News Reader

Self-XSS attack explained

facebook.com

79 pointsmkjones32 comments

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.

>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.

The XSS code could just be modified to automatically confirm its actions.

Not if it required a captcha.

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.

The XSS could change the text explaining the CAPTCHA and socially engineer people into solving it.

But then the 'evil script' would select all his friends minus one; or maybe just send messages one by one.

The only real way to eradicate this problem is what he is already trying to do: educate the users.

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.

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?

That's a good idea, and we actually thought about that. But assuming we need those APIs, what's to keep them from calling our wrappers around them?

Put another way, how do we determine if the caller of some of our js is malicious or is us?

It just needs to be non-predictable. Give the wrapper object and ALL his methods a random name for every session.

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.

Replace instructions with:

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.

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?

> 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.

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)

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.

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.

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.

Also, here is my blog post discussing an attack scenario: http://www.nathanhammond.com/social-engineering-issue-with-j...

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.

Not sure why anyone would legitimately use the address bar for js.

Bookmarklets, like http://kathack.com/.

Browsers can support bookmarklets without allowing javascript to be entered directly in the address bar.

Then the attack shifts. The "security check" becomes, drag this link to your bookmark bar and click it.

A solution to that for browser vendors: Don't let the user drag javascript links from iframes into the bookmark bar.

Why let users do anything in their browser? What if someone tricks them into jumping out their window?

Mobile web browsers sadly don't have console access like this so the address bar is the only way to go (ignoring scripts like weinre).

Reply on news.ycombinator.com