4 ms·

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

by 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.

by nknight 15y ago

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.