5 ms·

Facebook Vulnerability: Like Clickjacking

48 points by erickerr 16y ago

vinhboy 16y ago
http://vinhboy.com/blog/2010/05/31/facebook-man-with-the-biggest-trick/ http://vinhboy.com/blog/2010/05/31/facebook-man-with-the-big... I also wrote about this like 2 months ago, and they still haven't done anything about it... =(. Facebook CTO guy, are you around today?
- bkrausz 16y ago
  I'm not sure if this is even possible to fix, given the same-origin policy on iframes. Facebook can't tell where the iframe is placed on the page, and I don't think they can tell if it's 'position:absolute'd. It's a tough problem.
  - mdwrigh2 16y ago
    Sadly, you're right that there isn't a known solution to this yet. If you see my post below, it shows how even if they weren't in an iframe, there are still ways around current framebusting techniques.
  - vinhboy 16y ago
    Without testing, I suggest maybe making the iframe do an "alert" -- "Are you sure you want to Like this page?" One more step, a lot more security. Or at the very least make it easier to find things that you have liked ( I am speaking without actually going to look if its easy to find it... I just remember it was very hard to find the last time I tried )
    - bkrausz 16y ago
      Alert boxes tend to be horrible in terms of usability, but it is the only way to actually require a second step, since anything else you do will be constrained to the iframe and you can just clickjack a second time. I think the solution they'll end up implementing (if they do anything) is an "I didn't Like this" link that users can click to report false clicks. If a company gets more than x% of those they get taken down. It's not a legit solution but should be fairly effective.
      - mukyu 16y ago
        They can change the like to a 'pending like' and confirm it next time you check facebook.
        ctingom 16y ago
        And for "trusted" fan pages they could automatically bypass that.
  - jpeterson 16y ago
    Yes, but perhaps this is a sign of iframe abuse on the part of Facebook and the 3rd party site developers? Placing blame on the browser is pretty lame. The solution to this problem is to not mislead users by embedding one domain's content within another site in the first place.
  - photon_off 16y ago
    My other post describes the fix. I don't have a fancy blog to put up a demo, though.
- drivebyacct2 16y ago
  I'm happy to upvote your comment. This is way old news, its funny because even my tech friends are getting ensnared by it.
- finiteloop 16y ago
  Yes, I am here, and so is someone who is more knowledgable than I am: http://news.ycombinator.com/item?id=1513470 http://news.ycombinator.com/item?id=1513470
mdwrigh2 16y ago
Unfortunately, the twitter clickjacking attack still isn't fixed. See http://seclab.stanford.edu/websec/framebusting/index.php http://seclab.stanford.edu/websec/framebusting/index.php for an overview of how that type of defense still can be defeated.
bsnss-mn-cdr 16y ago
Items like this will always be a never ending battle. Each time one side has to update their technology to stop something from the other they normally must gain more authority from the other. In the case of Facebook that will be asking for more rights into each website that wants to use the 'Like' button and with the recent privacy issues this will just kick the hornets nest all over again.
- prodigal_erik 16y ago
  I see it as a battle between "the browser is a reliable tool for reading and navigating documents on the web" and "the browser is just another UI toolkit for trusted desktop applications". It can't be both, because any seamless UI will always be powerful enough for untrustworthy code to find other malicious tricks like this.
qeorge 16y ago
Its especially bad because of the way profile pages are organized. When you're viewing your own profile wall posts and status updates float to the top, while Likes, new friends, and other such ambient updates are further down. However, other people see the Like front and center on their News Feed. I noticed this after several friends were liking "10 WORST construction mistakes", or similar. I asked several about it, and none of them had any idea it had happened.
kwamenum86 16y ago
Anything in an iframe or under an iframe is susceptible to clickjacking. Firefox + NoScript does a pretty good job of preventing this.
mkjones 16y ago
This is Matt Jones, an engineer on the site integrity team at Facebook. We're the ones who address issues like this one on Facebook. Ultimately clickjacking / UI redress is a browser vulnerability - it shouldn't be possible to display one thing and have another receive user interactions. As some people have pointed out, Firefox's NoScript plugin does a pretty good job of preventing it. But that isn't to say victim web sites shouldn't do anything about it. In the case of Like buttons, they inherently run in an iframe so our protection on the rest of facebook.com (http://theharmonyguy.com/2010/03/13/facebook-adds-code-for-clickjacking-prevention/ http://theharmonyguy.com/2010/03/13/facebook-adds-code-for-c...) can't apply. However, Facebook knows the urls these buttons point to and generally knows or can infer the urls where they are embedded. When we detect a likejacking site on one of these urls, we block its url or domain from being liked and prevent future clicks on facebook.com from going to it.
- awa 16y ago
  I am pretty sure the users will come after facebook for the bug and not IE or firefox. It seems making the like button an iFrame is not the best idea coz of this bug. I don't go around submitting stuff to reddit/digg/HN/Twitter when I click somewhere on some site, so why facebook?
- photon_off 16y ago
  Hi Matt. First off, thank you for coming forth to make a statement about this vulnerability. It's nice to see that fb is responding to these incidents, and since you care, I'll work with you to solve the problem. But first, let me express how disconcerting I find it for facebook to "pass the buck" on the blame of this vulnerability. It's not a browser vulnerability to have personal information be shared by implementing a "1 click publishing" button via a cross-domain iframe that (often times unknowingly) has a user logged into another site -- it's a privacy vulnerability that you need to take care of. As of late, I see no way that I can disable "liking" stuff, and I'm aware of the vulnerability, so I stay logged out of Facebook as often as I can. It's facebook's decision to use an iframe, to publish content to user's news streams in 1 click, and to allow any website to implement the like button. It's your decision in spite of knowing that the means of doing so are open to "vulnerabilities" such as linkjacking. I put "vulnerability" in quotes because it's not really a vulnerability, now is it? It's a fundamental possibility based on how HTML works -- links can be invisible! Calling "linkjacking" a vulnerability is like calling tracking pixels, sessions in URLs, or anything that can be used for ill purposes, a "vulnerability" that browsers need to take care of. I'm not buying it. It's part of the design of HTML and you need to work with it. You could easily remedy the situation by ensuring the user really means to publish something. However, I realize you aren't going to change anything about the "liking" process because it will disincentivize publishers from including it if it's not as effective. Business first, I understand. Luckily, I will share with you, for free, how to fix this issue. You can detect whether or not an iframe is being invisibly dragged by polling the cursorX and cursorY (which are relative to the browser window itself, not just the iframe) in conjunction with whether or not the user's mouse is over the "like" button (simple onmouseover/onmouseout). If the user's mouse is over the "like" button even as X and Y dramatically change (optionally, over some unit of time) then the iframe is being positioned according to the mouse movements. A click on the "like" button should be disabled, and you should discretely notify your server that the URL/domain is suspect. If the attackers were smarter, they'd position the "like" button below the mouse only on an onmousedown event so that your detection script wouldn't catch on to the one sudden movement of the "like" button in time for when the user lifts the button of their mouse. But, luckily, you'd have me to tell you to ensure that both onmousedown and onmouseup are fired before actually having the "like" button signal a click. So, there you have it. A free solution to your problem. That worked out much easier than posting a puzzle on your jobs page and waiting for people to solve your problems that way. PS: For some reason as I read my post I realize that I come off as quite arrogant and perhaps a bit angsty. I apologize for that... it's almost embarrassing. I think it's just really late and I felt like being really frank about the issue. At any rate, you guys should hire me.

48 points by erickerr 16y ago

http://vinhboy.com/blog/2010/05/31/facebook-man-with-the-biggest-trick/ http://vinhboy.com/blog/2010/05/31/facebook-man-with-the-big... I also wrote about this like 2 months ago, and they still haven't done anything about it... =(. Facebook CTO guy, are you around today?

bkrausz 16y ago
I'm not sure if this is even possible to fix, given the same-origin policy on iframes. Facebook can't tell where the iframe is placed on the page, and I don't think they can tell if it's 'position:absolute'd. It's a tough problem.
- mdwrigh2 16y ago
  Sadly, you're right that there isn't a known solution to this yet. If you see my post below, it shows how even if they weren't in an iframe, there are still ways around current framebusting techniques.
- vinhboy 16y ago
  Without testing, I suggest maybe making the iframe do an "alert" -- "Are you sure you want to Like this page?" One more step, a lot more security. Or at the very least make it easier to find things that you have liked ( I am speaking without actually going to look if its easy to find it... I just remember it was very hard to find the last time I tried )
  - bkrausz 16y ago
    Alert boxes tend to be horrible in terms of usability, but it is the only way to actually require a second step, since anything else you do will be constrained to the iframe and you can just clickjack a second time. I think the solution they'll end up implementing (if they do anything) is an "I didn't Like this" link that users can click to report false clicks. If a company gets more than x% of those they get taken down. It's not a legit solution but should be fairly effective.
    - mukyu 16y ago
      They can change the like to a 'pending like' and confirm it next time you check facebook.
      - ctingom 16y ago
        And for "trusted" fan pages they could automatically bypass that.
- jpeterson 16y ago
  Yes, but perhaps this is a sign of iframe abuse on the part of Facebook and the 3rd party site developers? Placing blame on the browser is pretty lame. The solution to this problem is to not mislead users by embedding one domain's content within another site in the first place.
- photon_off 16y ago
  My other post describes the fix. I don't have a fancy blog to put up a demo, though.
drivebyacct2 16y ago
I'm happy to upvote your comment. This is way old news, its funny because even my tech friends are getting ensnared by it.
finiteloop 16y ago
Yes, I am here, and so is someone who is more knowledgable than I am: http://news.ycombinator.com/item?id=1513470 http://news.ycombinator.com/item?id=1513470

mdwrigh2 16y ago

Unfortunately, the twitter clickjacking attack still isn't fixed. See http://seclab.stanford.edu/websec/framebusting/index.php http://seclab.stanford.edu/websec/framebusting/index.php for an overview of how that type of defense still can be defeated.

bsnss-mn-cdr 16y ago

Items like this will always be a never ending battle. Each time one side has to update their technology to stop something from the other they normally must gain more authority from the other. In the case of Facebook that will be asking for more rights into each website that wants to use the 'Like' button and with the recent privacy issues this will just kick the hornets nest all over again.

prodigal_erik 16y ago
I see it as a battle between "the browser is a reliable tool for reading and navigating documents on the web" and "the browser is just another UI toolkit for trusted desktop applications". It can't be both, because any seamless UI will always be powerful enough for untrustworthy code to find other malicious tricks like this.

qeorge 16y ago

Its especially bad because of the way profile pages are organized. When you're viewing your own profile wall posts and status updates float to the top, while Likes, new friends, and other such ambient updates are further down. However, other people see the Like front and center on their News Feed. I noticed this after several friends were liking "10 WORST construction mistakes", or similar. I asked several about it, and none of them had any idea it had happened.

kwamenum86 16y ago

Anything in an iframe or under an iframe is susceptible to clickjacking. Firefox + NoScript does a pretty good job of preventing this.

mkjones 16y ago

This is Matt Jones, an engineer on the site integrity team at Facebook. We're the ones who address issues like this one on Facebook. Ultimately clickjacking / UI redress is a browser vulnerability - it shouldn't be possible to display one thing and have another receive user interactions. As some people have pointed out, Firefox's NoScript plugin does a pretty good job of preventing it. But that isn't to say victim web sites shouldn't do anything about it. In the case of Like buttons, they inherently run in an iframe so our protection on the rest of facebook.com (http://theharmonyguy.com/2010/03/13/facebook-adds-code-for-clickjacking-prevention/ http://theharmonyguy.com/2010/03/13/facebook-adds-code-for-c...) can't apply. However, Facebook knows the urls these buttons point to and generally knows or can infer the urls where they are embedded. When we detect a likejacking site on one of these urls, we block its url or domain from being liked and prevent future clicks on facebook.com from going to it.

awa 16y ago
I am pretty sure the users will come after facebook for the bug and not IE or firefox. It seems making the like button an iFrame is not the best idea coz of this bug. I don't go around submitting stuff to reddit/digg/HN/Twitter when I click somewhere on some site, so why facebook?
photon_off 16y ago
Hi Matt. First off, thank you for coming forth to make a statement about this vulnerability. It's nice to see that fb is responding to these incidents, and since you care, I'll work with you to solve the problem. But first, let me express how disconcerting I find it for facebook to "pass the buck" on the blame of this vulnerability. It's not a browser vulnerability to have personal information be shared by implementing a "1 click publishing" button via a cross-domain iframe that (often times unknowingly) has a user logged into another site -- it's a privacy vulnerability that you need to take care of. As of late, I see no way that I can disable "liking" stuff, and I'm aware of the vulnerability, so I stay logged out of Facebook as often as I can. It's facebook's decision to use an iframe, to publish content to user's news streams in 1 click, and to allow any website to implement the like button. It's your decision in spite of knowing that the means of doing so are open to "vulnerabilities" such as linkjacking. I put "vulnerability" in quotes because it's not really a vulnerability, now is it? It's a fundamental possibility based on how HTML works -- links can be invisible! Calling "linkjacking" a vulnerability is like calling tracking pixels, sessions in URLs, or anything that can be used for ill purposes, a "vulnerability" that browsers need to take care of. I'm not buying it. It's part of the design of HTML and you need to work with it. You could easily remedy the situation by ensuring the user really means to publish something. However, I realize you aren't going to change anything about the "liking" process because it will disincentivize publishers from including it if it's not as effective. Business first, I understand. Luckily, I will share with you, for free, how to fix this issue. You can detect whether or not an iframe is being invisibly dragged by polling the cursorX and cursorY (which are relative to the browser window itself, not just the iframe) in conjunction with whether or not the user's mouse is over the "like" button (simple onmouseover/onmouseout). If the user's mouse is over the "like" button even as X and Y dramatically change (optionally, over some unit of time) then the iframe is being positioned according to the mouse movements. A click on the "like" button should be disabled, and you should discretely notify your server that the URL/domain is suspect. If the attackers were smarter, they'd position the "like" button below the mouse only on an onmousedown event so that your detection script wouldn't catch on to the one sudden movement of the "like" button in time for when the user lifts the button of their mouse. But, luckily, you'd have me to tell you to ensure that both onmousedown and onmouseup are fired before actually having the "like" button signal a click. So, there you have it. A free solution to your problem. That worked out much easier than posting a puzzle on your jobs page and waiting for people to solve your problems that way. PS: For some reason as I read my post I realize that I come off as quite arrogant and perhaps a bit angsty. I apologize for that... it's almost embarrassing. I think it's just really late and I felt like being really frank about the issue. At any rate, you guys should hire me.