Hacker News Reader

Comment by nknight | Hacker News Reader

The report the KDE devs filed ( 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.

View on HN

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

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.

Reply on news.ycombinator.com