After some hours of trial and error I understood that an application has almost full access to user data by using REST-Ful APIs.
It seems that an application just needs a key called session_key representing the user.
How to get that? Redirecting the user to the facebook page (FacebookWiki):
http://www.facebook.com/tos.php?api_key=[AppKey]&moreParameters
Which, if user has already subscribed to the application, then it redirects to :
http://apps.facebook.com/appPage/?session={"session_key":"2.XXXXXXXXZzHYZaBMEA__.3600.XXXX-XXXXX","uid":XXXXXX,"expires":1271016000,"secret":"XXXXXX","base_domain":"domain.com","sig":"XXXXX"}
The url where the user is redirected can be set in the 'next' parameter (implied in moreParameters).
Now I had to better understand what I can do and went to my favourite FaceBook hacker-superhero The Harmony Guy.
Found this:
It seems he already found something...and very big! :( Even if I don't know a thing about FBK, I was sooo near!
The good^N^N^N^NBad thing is that it took me a few hours to study the environment and think about that.
That's the explaination (from harmony guy link):
"...
But the first main component of the attack involved a slight modification to
the login page URI. By adding a 'next' parameter, once can specify an
alternate landing page for authorized users. Not all applications take
advantage of this parameter, but many do. The parameter would not work
for an arbitrary site, but Facebook previously did allow any URI that began
with apps.facebook.com. Thus one could craft a login page URI that
checked whether the user had authorized one application and then
forward the user to a second application. The next part of the attack came
from adding 'return_session=1' to the login page URI. This parameter
causes Facebook to append particular session variables for the authorized
application onto the URI of the landing page - in our case, the second
application given by the 'next' parameter. That application merely has to
check its address for the session data, which provides enough information
to execute API requests using the credentials of the already authorized
application.
..."
Now there's something I don't understand, and that's because I'm not a Facebook hacker and because the description is not technical.
They say it's fixed but if I try this request:
http://www.facebook.com/tos.php?api_key=80c6ec6628efd9a465dd223190a65bbc&connect_display=popup&v=1.0&next=../wisectest/&v=1.0&&return_session=true&session_key_only=true&canvas
using farmville api_key with next parameter set to my test application home page on apps.facebook.com, I get a redirect to:
http://apps.facebook.com/wisectest/?session={"session_key":"2.XXXXXXXXZzHYZaBMEA__.3600.XXXX-XXXXX","uid":XXXXXX,"expires":1271016000,"secret":"XXXXXX","base_domain":"farmville.com","sig":"XXXXX"}
After that the victim seems to be also added my fake test app transparently...
Maybe they fixed on login.php but missed some page?...:o
As usual the infamous question I asked myself a lot of times when a vuln is fixed but the technique has not been understood.
How come that after the "theharmonyguy" post no one @facebook got a deep analysis?
Maybe complexity is a bad dwarf when dealing with security, but what about applying Secure-SLDC, I mean, really.
Just for sake of user privacy protection, I'd suggest to use different Browsers or Firefox Plugins.
- Use Chrome for your every day browsing
- Use (at least) multiple profiles on Firefox for your favorite categories
- Firefox -P private
- Firefox -P banking
- Firefox -P pr0n
- Firefox -P whatever
and, of course use NoScript! ;)
- Firefox -P private
Nota Bene:
I also found some site publishing Xss on facebook applications by simply searching on google...and they still work!
Hey Mr. Facebook would you care doing a Google search?
A hint: "facebook applications security bugs" on bigG.