4 ms·

They have a special desktop API that solves this exact issue. EDIT: they used to, at least. They now want devs to use the web OAuth flow by adding an embedde

by teej 15y ago

They have a special desktop API that solves this exact issue. EDIT: they used to, at least. They now want devs to use the web OAuth flow by adding an embedded web view to your desktop app. http://developers.facebook.com/docs/authentication/ http://developers.facebook.com/docs/authentication/

nknight 15y ago
The report the KDE devs filed ( http://bugs.developers.facebook.net/show_bug.cgi?id=18701 http://bugs.developers.facebook.net/show_bug.cgi?id=18701 ) addresses this directly: The way OAuth2 is handled by your platform allows in principle anyone to impersonate our application, as all that's needed is getting to know our application ID, which can be easily obtained from the URL of the application page. If you feel our application has been used to send spam to other users, it has certainly not been done by our code.
- saurik 15y ago
  While this is true, having opted to /not/ use the OAuth 2.0 flow (which at least limits you to having access only to the access_token for that one user) and instead distributing the access/secret key for the app (which is what this developer decided to do instead) is so much less secure that I don't have much sympathy this developer in his complaint that Facebook doesn't really support desktop apps (which is, honestly, a hard problem).
  - deleted 15y ago
    [deleted]
  - nknight 15y ago
    Well, they _do_ use OAuth. If you keep reading the code, the API key is there for a convenience function to "upgrade" an already-active non-OAuth session through what looks to be a Facebook-sanctioned mechanism. /** * upgrade session key to OAuth * * This method (or step) can be removed after June 2012 (a year after its * implementation), since it is only a convenience method for those people * who just upgraded and have an active session using the old authentication. */ Does the secretKey actually work for anything other than swapping out the session type? I don't know. Edit: Actually, it appears the code was largely unmaintained for a couple years, and the OAuth mechanism was just added to trunk a week ago. So this would still be a problem for the existing deployments
  - deleted 15y ago
    [deleted]
- arcs 15y ago
  Correct me if I'm wrong, but it seems that while using the client-side auth flow does not prevent a malicious program from pretending to be another facebook app, it forces the malicious application to be downloaded and executed as it must be able to catch the redirect to a different url with the access token, which a web app cannot do. Once you are downloading and executing a malicious native app, you're screwed anyways since it can do whatever it wants like read your cookies and hijack running applications... (I'm not considering java or flash applets, depending on how their security works this may still allow drive-by spammage as a legit app). It does allow a malicious user to easily write something that impersonates a legit application, though it's limited to spamming his own account.
fleitz 15y ago
How does using the OAuth flow on a desktop app solve any of these issues? If you have the app binary, you have the secret key. It's simply a matter of attaching a debugger and waiting for the URL handler to be called. Even the trick auth flow on iphone where it opens the Facebook app has the same vulnerability.
- saurik 15y ago
  The OAuth 2.0 flow, as far as I can tell, does not require you distributing your secret key, which is what this application was doing. From Facebook's documentation: "The app secret is available from the Developer App and should not be shared with anyone or embedded in any code that you will distribute (you should use the client-side flow for these scenarios)."
- nl 15y ago
  If you have the app binary, you have the secret key. No, you have the access token. There's a big difference. It's simply a matter of attaching a debugger and waiting for the URL handler to be called. Even the trick auth flow on iphone where it opens the Facebook app has the same vulnerability. Yep, you can do that. But then all you know how to authorize the app to act on your (the logged on user) behalf. You can write another application that pretends to be that app, but since it acts on your behalf I'm not sure that's a big risk. In the case of this KDE program, not only do you know how to make the app act on your behalf - but (as the OP noted) - it is probably possible to make the application act on behalf of any other user that has authorized this application id. That's a pretty bad problem. It sucks for the legitimate users who uploaded the pics using it, but who knows what else got uploaded to other people's accounts using this program? I suspect that's the reason why Facebook didn't just bad the app, but had to delete pics as well.

by teej 15y ago

nknight 15y ago

The report the KDE devs filed ( http://bugs.developers.facebook.net/show_bug.cgi?id=18701 http://bugs.developers.facebook.net/show_bug.cgi?id=18701 ) addresses this directly: The way OAuth2 is handled by your platform allows in principle anyone to impersonate our application, as all that's needed is getting to know our application ID, which can be easily obtained from the URL of the application page. If you feel our application has been used to send spam to other users, it has certainly not been done by our code.

saurik 15y ago
While this is true, having opted to /not/ use the OAuth 2.0 flow (which at least limits you to having access only to the access_token for that one user) and instead distributing the access/secret key for the app (which is what this developer decided to do instead) is so much less secure that I don't have much sympathy this developer in his complaint that Facebook doesn't really support desktop apps (which is, honestly, a hard problem).
- deleted 15y ago
  [deleted]
- nknight 15y ago
  Well, they _do_ use OAuth. If you keep reading the code, the API key is there for a convenience function to "upgrade" an already-active non-OAuth session through what looks to be a Facebook-sanctioned mechanism. /** * upgrade session key to OAuth * * This method (or step) can be removed after June 2012 (a year after its * implementation), since it is only a convenience method for those people * who just upgraded and have an active session using the old authentication. */ Does the secretKey actually work for anything other than swapping out the session type? I don't know. Edit: Actually, it appears the code was largely unmaintained for a couple years, and the OAuth mechanism was just added to trunk a week ago. So this would still be a problem for the existing deployments
- deleted 15y ago
  [deleted]
arcs 15y ago
Correct me if I'm wrong, but it seems that while using the client-side auth flow does not prevent a malicious program from pretending to be another facebook app, it forces the malicious application to be downloaded and executed as it must be able to catch the redirect to a different url with the access token, which a web app cannot do. Once you are downloading and executing a malicious native app, you're screwed anyways since it can do whatever it wants like read your cookies and hijack running applications... (I'm not considering java or flash applets, depending on how their security works this may still allow drive-by spammage as a legit app). It does allow a malicious user to easily write something that impersonates a legit application, though it's limited to spamming his own account.

fleitz 15y ago

How does using the OAuth flow on a desktop app solve any of these issues? If you have the app binary, you have the secret key. It's simply a matter of attaching a debugger and waiting for the URL handler to be called. Even the trick auth flow on iphone where it opens the Facebook app has the same vulnerability.

saurik 15y ago
The OAuth 2.0 flow, as far as I can tell, does not require you distributing your secret key, which is what this application was doing. From Facebook's documentation: "The app secret is available from the Developer App and should not be shared with anyone or embedded in any code that you will distribute (you should use the client-side flow for these scenarios)."
nl 15y ago
If you have the app binary, you have the secret key. No, you have the access token. There's a big difference. It's simply a matter of attaching a debugger and waiting for the URL handler to be called. Even the trick auth flow on iphone where it opens the Facebook app has the same vulnerability. Yep, you can do that. But then all you know how to authorize the app to act on your (the logged on user) behalf. You can write another application that pretends to be that app, but since it acts on your behalf I'm not sure that's a big risk. In the case of this KDE program, not only do you know how to make the app act on your behalf - but (as the OP noted) - it is probably possible to make the application act on behalf of any other user that has authorized this application id. That's a pretty bad problem. It sucks for the legitimate users who uploaded the pics using it, but who knows what else got uploaded to other people's accounts using this program? I suspect that's the reason why Facebook didn't just bad the app, but had to delete pics as well.