After watching the video, it looks like the exploit involves:
1) Getting the target user's userId. This used to be part of a user's profile URL but Facebook allowed people to choose a "vanity URL" quite a while ago, so they're no longer as visible. So, instead, the userId is obtained from a FB Graph API query.
2) The form that makes up the "post to newsfeed" has a bunch of hidden inputs. One of them refers to a "xhpc_targetid" and this is probably where the target userId is injected. It's normally set to the current user's id for a default newsfeed post. These values in the DOM are modified during the exploit using something like Chrome Developer Tools on-the-fly and the form is submitted.
If this is truly the case (and I haven't verified it myself) this means that the server side is not really checking permissions and just blindly trusting the client input. Reminded me of this recent (http://arstechnica.com/information-technology/2013/08/how-ea...) article about trusting client input.
This is a pretty vicious error but common one...it sounds like the analogue to Rails' mass-assignment default protections, which were exploited on Github by tampering with the params via inspector.
Coincidentally, that bug was also exposed by a non-native English speaker who was dismissed for his inability to fluently express himself.
no, i was dismissed for some other reason. My emails (i reread them a while ago) explained perfectly where's the bug.
On this topic: i still have no clue what vulnerability it was. Guy, do you know such terms XSS, CSRF etc? Can't u just say where's the bug, nobody wants to watch 6 (!) minutes long video with arabic subtitles rofl. peace
Correct. Sorry, didn't mean to imply it was hard to obtain this value (the switch to vanity URL part was more of an anecdote) but just to describe what happened in the video of the exploit.
I'd be surprised if this were actually the exploit. If it were, I don't think it would have stayed undiscovered for so long. I'm sure that changing the "xhpc_targetid" was one component of the hack, but some of the other inputs probably had to be manipulated as well.
1) Getting the target user's userId. This used to be part of a user's profile URL but Facebook allowed people to choose a "vanity URL" quite a while ago, so they're no longer as visible. So, instead, the userId is obtained from a FB Graph API query.
2) The form that makes up the "post to newsfeed" has a bunch of hidden inputs. One of them refers to a "xhpc_targetid" and this is probably where the target userId is injected. It's normally set to the current user's id for a default newsfeed post. These values in the DOM are modified during the exploit using something like Chrome Developer Tools on-the-fly and the form is submitted.
If this is truly the case (and I haven't verified it myself) this means that the server side is not really checking permissions and just blindly trusting the client input. Reminded me of this recent (http://arstechnica.com/information-technology/2013/08/how-ea...) article about trusting client input.