6 ms·

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 /

by 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.
- mkjones 16y ago
  The idea of detecting if X and Y are changing while the cursor is over the button is a good one and actually something we thought about. While it does help mitigate the case where the attacking site dynamically moves the iframe, it's relatively easy to position the like button statically and just trick the user into clicking on its particular location, which would bypass this strategy (albeit at the cost of a slightly lower clickthrough rate). So I don't think this is a robust enough fix. I think it's reasonable to say that clickjacking / UI redressing attacks are a browser bug - it's addressed in Google's browser security handbook: http://code.google.com/p/browsersec/wiki/Part2#Arbitrary_page_mashups_%28UI_redressing%29 http://code.google.com/p/browsersec/wiki/Part2#Arbitrary_pag.... But regardless - we as a victim site are mitigating the problem. Do you think there's a better way to offer the one-click liking experience without an iframe?
  - photon_off 16y ago
    Fair point about the statically placed and baited frames. Well, detecting X and Y would solve the movable case of this, so that's better than nothing. After reading that handbook link, I'd agree that it is very reasonable to consider it a browser bug. I suppose I considered it more of an oversight in terms of iframe specifications, and now am more sympathetic to your situation. I'm not sure there's a better way to offer a one-click liking experience. If I'm not mistaken, you have two options: more than 1 click, or be vulnerable to these attacks. Personally, I'd use the feature more if it behaved the same way that pasting a URL into my status does. In this case, it would be 1 click to open some sort of floating dialog (or a small window like in fbConnect), and another click to change the title, add a description, or just click "ok". ... pause for 10 minutes ... Perhaps this might be a solution. An embedded javascript (sourced to your server) returns a code with a unique key for that user/URL combination (along with whether or not they have already pressed it), stored in javascript in a private data structure (an anonymous function, for example). You then embed whatever HTML you need to display your button onto that page, along with code to ensure it is being intentionally clicked. On click, you load another js file, where the unique key is passed via the get parameter. Your server will process the like, and this file will return the javascript to set the button as depressed, or to request the user login, or whatever. The reason that the key is stored in an anonymous function is so the host URL cannot retrieve this bit. Otherwise, they could simply call the second js file to automate the user "liking" their page. The calls to your js file, however, still allow you to get the user's session data. And, of course, you can execute JS on the host's end to ensure that the click is legitimate.. Is this flawed? What do you think? Edit: I just realized that "legitimate click detection" would be very involved. But, still possible.
DennisP 16y ago
Since the browser behavior existed before Facebook implemented this feature, the responsibility is Facebook's.

by mkjones 16y ago

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.

mkjones 16y ago
The idea of detecting if X and Y are changing while the cursor is over the button is a good one and actually something we thought about. While it does help mitigate the case where the attacking site dynamically moves the iframe, it's relatively easy to position the like button statically and just trick the user into clicking on its particular location, which would bypass this strategy (albeit at the cost of a slightly lower clickthrough rate). So I don't think this is a robust enough fix. I think it's reasonable to say that clickjacking / UI redressing attacks are a browser bug - it's addressed in Google's browser security handbook: http://code.google.com/p/browsersec/wiki/Part2#Arbitrary_page_mashups_%28UI_redressing%29 http://code.google.com/p/browsersec/wiki/Part2#Arbitrary_pag.... But regardless - we as a victim site are mitigating the problem. Do you think there's a better way to offer the one-click liking experience without an iframe?
- photon_off 16y ago
  Fair point about the statically placed and baited frames. Well, detecting X and Y would solve the movable case of this, so that's better than nothing. After reading that handbook link, I'd agree that it is very reasonable to consider it a browser bug. I suppose I considered it more of an oversight in terms of iframe specifications, and now am more sympathetic to your situation. I'm not sure there's a better way to offer a one-click liking experience. If I'm not mistaken, you have two options: more than 1 click, or be vulnerable to these attacks. Personally, I'd use the feature more if it behaved the same way that pasting a URL into my status does. In this case, it would be 1 click to open some sort of floating dialog (or a small window like in fbConnect), and another click to change the title, add a description, or just click "ok". ... pause for 10 minutes ... Perhaps this might be a solution. An embedded javascript (sourced to your server) returns a code with a unique key for that user/URL combination (along with whether or not they have already pressed it), stored in javascript in a private data structure (an anonymous function, for example). You then embed whatever HTML you need to display your button onto that page, along with code to ensure it is being intentionally clicked. On click, you load another js file, where the unique key is passed via the get parameter. Your server will process the like, and this file will return the javascript to set the button as depressed, or to request the user login, or whatever. The reason that the key is stored in an anonymous function is so the host URL cannot retrieve this bit. Otherwise, they could simply call the second js file to automate the user "liking" their page. The calls to your js file, however, still allow you to get the user's session data. And, of course, you can execute JS on the host's end to ensure that the click is legitimate.. Is this flawed? What do you think? Edit: I just realized that "legitimate click detection" would be very involved. But, still possible.

DennisP 16y ago

Since the browser behavior existed before Facebook implemented this feature, the responsibility is Facebook's.