Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Facebook bans KDE application, deletes user photos

networkworld.com

Post reply on HN
Print view View original

11–20 of 45 posts

Re: Facebook bans KDE application, deletes user photos

#11

Post by sid0 »

saurik wrote: post #5

From the error, it actually sounds like the application had an API key distributed inside of it... which means that anyone, anywhere, could pretend to be the application.. and could use its credentials to upload anything they want. Yeah, right here: fbtalker.cpp: m_apiKey = "bf430ad869b88aba5c0c17ea6707022b"; fbtalker.cpp: m_secretKey = "0434307e70dd12c414cc6d0928f132d8"; To be honest, as much as I hate Facebook's de…

How would a client-side application access the Facebook API if it didn't distribute the API key?

Re: Facebook bans KDE application, deletes user photos

#12

Post by saurik »

sid0 wrote: post #11
saurik wrote: post #5

From the error, it actually sounds like the application had an API key distributed inside of it... which means that anyone, anywhere, could pretend to be the application.. and could use its credentials to upload anything they want. Yeah, right here: fbtalker.cpp: m_apiKey = "bf430ad869b88aba5c0c17ea6707022b"; fbtalker.cpp: m_secretKey = "0434307e70dd12c414cc6d0928f132d8"; To be honest, as much as I hate Facebook's de…

How would a client-side application access the Facebook API if it didn't distribute the API key?

OAuth 2.0. The mechanism Facebook is a little screwed up and frankly seems somewhat insecure itself, but it is still going to be hundreds of times better than distributing your /secret key/ in your app.

For more details, scroll down to "Desktop Apps" (which is near the bottom) on Facebook's authentication documentation:

https://developers.facebook.com/docs/authentication/

Re: Facebook bans KDE application, deletes user photos

#13

Post by nknight »

teej wrote: post #9
fleitz wrote: post #7

Earlier quoted context omitted.

How exactly does one solve this issue? Facebook's auth/app system makes a whole lot of sense for web sites but zero sense for desktop/mobile apps. The app is not insecure, how does exposing two keys endanger ANY user data? iPhone apps have the EXACT same issue, as this application, give me an IPA file and I'll give you the app's keys. Look at Facebook's official docs and they recommend embedding the keys into the app…

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/

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.

Re: Facebook bans KDE application, deletes user photos

#14

Post by wheels »

saurik wrote: post #5

From the error, it actually sounds like the application had an API key distributed inside of it... which means that anyone, anywhere, could pretend to be the application.. and could use its credentials to upload anything they want. Yeah, right here: fbtalker.cpp: m_apiKey = "bf430ad869b88aba5c0c17ea6707022b"; fbtalker.cpp: m_secretKey = "0434307e70dd12c414cc6d0928f132d8"; To be honest, as much as I hate Facebook's de…

It's not like compiling it in would have helped:

  satie: /usr/lib/kde4> strings kipiplugin_facebook.so | grep -P "[0-9a-f]{32}"
  bf430ad869b88aba5c0c17ea6707022b
  0434307e70dd12c414cc6d0928f132d8
I just picked the plugin in question since its keys are already pasted all over the interwebs, but I presume it would be similarly trivial to pull the keys out of most desktop apps.

Re: Facebook bans KDE application, deletes user photos

#15

Post by saurik »

wheels wrote: post #14
saurik wrote: post #5

From the error, it actually sounds like the application had an API key distributed inside of it... which means that anyone, anywhere, could pretend to be the application.. and could use its credentials to upload anything they want. Yeah, right here: fbtalker.cpp: m_apiKey = "bf430ad869b88aba5c0c17ea6707022b"; fbtalker.cpp: m_secretKey = "0434307e70dd12c414cc6d0928f132d8"; To be honest, as much as I hate Facebook's de…

It's not like compiling it in would have helped: satie: /usr/lib/kde4> strings kipiplugin_facebook.so | grep -P "[0-9a-f]{32}" bf430ad869b88aba5c0c17ea6707022b 0434307e70dd12c414cc6d0928f132d8 I just picked the plugin in question since its keys are already pasted all over the interwebs, but I presume it would be similarly trivial to pull the keys out of most desktop apps.

Hence why I said: "open source or not: doesn't matter". The insecurity here is including your application's authentication credentials in any format that is ending up on an unsecured system.

Re: Facebook bans KDE application, deletes user photos

#16

Post by fleitz »

teej wrote: post #9
fleitz wrote: post #7

Earlier quoted context omitted.

How exactly does one solve this issue? Facebook's auth/app system makes a whole lot of sense for web sites but zero sense for desktop/mobile apps. The app is not insecure, how does exposing two keys endanger ANY user data? iPhone apps have the EXACT same issue, as this application, give me an IPA file and I'll give you the app's keys. Look at Facebook's official docs and they recommend embedding the keys into the app…

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/

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.

Re: Facebook bans KDE application, deletes user photos

#17

Post by saurik »

nknight wrote: post #13
teej wrote: post #9

Earlier quoted context omitted.

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/

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…

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

Re: Facebook bans KDE application, deletes user photos

#18

Post by saurik »

fleitz wrote: post #16
teej wrote: post #9

Earlier quoted context omitted.

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/

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.

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

Re: Facebook bans KDE application, deletes user photos

#19

Post by wladimir »

saurik wrote: post #12
sid0 wrote: post #11

Earlier quoted context omitted.

How would a client-side application access the Facebook API if it didn't distribute the API key?

OAuth 2.0. The mechanism Facebook is a little screwed up and frankly seems somewhat insecure itself, but it is still going to be hundreds of times better than distributing your /secret key/ in your app. For more details, scroll down to "Desktop Apps" (which is near the bottom) on Facebook's authentication documentation: https://developers.facebook.com/docs/authentication/

Does this avoid embedding keys in the application itself?

IMO it's kind of impossible to reliably 'authenticate' a desktop application.

Re: Facebook bans KDE application, deletes user photos

#20

Post by arcs »

nknight wrote: post #13
teej wrote: post #9

Earlier quoted context omitted.

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/

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…

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.

Post reply on HN