4 ms·

Self-XSS attack explained

79 points by mkjones 15y ago

Rygu 15y ago
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.
- eurleif 15y ago
  >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.
  - lancefisher 15y ago
    Not if it required a captcha.
    - eurleif 15y ago
      The XSS could change the text explaining the CAPTCHA and socially engineer people into solving it.
    - jQueryIsAwesome 15y ago
      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.
    - callahad 15y ago
      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.
      - mkjones 15y ago
        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.
- mkjones 15y ago
  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.
  - codejoust 15y ago
    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?
    - mkjones 15y ago
      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?
      - jQueryIsAwesome 15y ago
        It just needs to be non-predictable. Give the wrapper object and ALL his methods a random name for every session.
- boucher 15y ago
  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.
  - Me1000 15y ago
    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.
    - davej 15y ago
      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.
      - Too 15y ago
        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.
- forgotusername 15y ago
  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.
- rplnt 15y ago
  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.
  - Timothee 15y ago
    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.
bialecki 15y ago
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.
- mkjones 15y ago
  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.
  - jrockway 15y ago
    Not sure why anyone would legitimately use the address bar for js. Bookmarklets, like http://kathack.com/ http://kathack.com/.
    - re 15y ago
      Browsers can support bookmarklets without allowing javascript to be entered directly in the address bar.
      - scotth 15y ago
        Then the attack shifts. The "security check" becomes, drag this link to your bookmark bar and click it.
        simonbrown 15y ago
        A solution to that for browser vendors: Don't let the user drag javascript links from iframes into the bookmark bar.
rsoto 15y ago
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?
- Timothee 15y ago
  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.
- lbrandy 15y ago
  > 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.
  - rsoto 15y ago
    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-clipboard-in-javascript 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)
    - mkjones 15y ago
      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.
nathanhammond 15y ago
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 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-javascript-urls http://www.nathanhammond.com/social-engineering-issue-with-j...

79 points by mkjones 15y ago

Rygu 15y ago

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.

eurleif 15y ago
>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.
- lancefisher 15y ago
  Not if it required a captcha.
  - eurleif 15y ago
    The XSS could change the text explaining the CAPTCHA and socially engineer people into solving it.
  - jQueryIsAwesome 15y ago
    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.
  - callahad 15y ago
    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.
    - mkjones 15y ago
      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.
mkjones 15y ago
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.
- codejoust 15y ago
  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?
  - mkjones 15y ago
    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?
    - jQueryIsAwesome 15y ago
      It just needs to be non-predictable. Give the wrapper object and ALL his methods a random name for every session.
boucher 15y ago
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.
- Me1000 15y ago
  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.
  - davej 15y ago
    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.
    - Too 15y ago
      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.
forgotusername 15y ago
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.
rplnt 15y ago
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.
- Timothee 15y ago
  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.

bialecki 15y ago

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.

mkjones 15y ago
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.
- jrockway 15y ago
  Not sure why anyone would legitimately use the address bar for js. Bookmarklets, like http://kathack.com/ http://kathack.com/.
  - re 15y ago
    Browsers can support bookmarklets without allowing javascript to be entered directly in the address bar.
    - scotth 15y ago
      Then the attack shifts. The "security check" becomes, drag this link to your bookmark bar and click it.
      - simonbrown 15y ago
        A solution to that for browser vendors: Don't let the user drag javascript links from iframes into the bookmark bar.

rsoto 15y ago

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?

Timothee 15y ago
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.
lbrandy 15y ago
> 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.
- rsoto 15y ago
  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-clipboard-in-javascript 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)
  - mkjones 15y ago
    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.

nathanhammond 15y ago

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 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-javascript-urls http://www.nathanhammond.com/social-engineering-issue-with-j...