Facebook bans KDE application, deletes user photos
networkworld.com
networkworld.com
Yeah, right here:
fbtalker.cpp: m_apiKey = "bf430ad869b88aba5c0c17ea6707022b";
fbtalker.cpp: m_secretKey = "0434307e70dd12c414cc6d0928f132d8";
In fact, I'm a little rusty on this whole Facebook API thing, but I could easily see situations where the application was authorized to access peoples' photo galleries, then allowing anyone with those API keys to upload photos /as other people/. This likely went unnoticed for a while, but eventually someone figured it out, uploaded porn to /someone else's account/, and then the only feasible way to fix the situation (assuming a person even bothered looking into it, and I wouldn't blame Facebook much if no one did) was to just pull all photos that had been uploaded.
Seriously: this is not a situation of "do not use Facebook": this is a situation of "do not use insecure applications".
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 in this manner.
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/
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.
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.
"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)."
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.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.
satie: /usr/lib/kde4> strings kipiplugin_facebook.so | grep -P "[0-9a-f]{32}"
bf430ad869b88aba5c0c17ea6707022b
0434307e70dd12c414cc6d0928f132d8
Personally, having used the kipi plugins with Facebook since, I don't know, the last 3 years to upload photos I very much would blame them for not even bothering to try and fix it and just deleting probably 100,000s (millions?) of images on a whim.
Stop the API being used, message people who've used the plugin to check their photos, job done.
Argh!
But of course, this is 2011 and we can't rely on a real person being there at all anymore. Companies are lazy and just "flip the switch" without consideration for users. :(
Also, I never knew you lurked HN, saurik! ;P
You must not give your secret key to another party, unless that party is an agent acting on your behalf as an operator of your application. You are responsible for all activities that occur under your account identifiers.For more details, scroll down to "Desktop Apps" (which is near the bottom) on Facebook's authentication documentation:
IMO it's kind of impossible to reliably 'authenticate' a desktop application.
"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)."
As far as I know, a lot of iPhone apps are shipped with App key and secret key. (For example, an open source project for sharing requires you to put your app's secret key: http://getsharekit.com/)
Regardless, if you read the documentation that I keep referring (and even linking to), it has a very clear (if arguably stupid seeming) mechanism for desktop applications to operate: you use the OAuth 2.0 flow, but have the landing page be a specially designated page on Facebook's server. Then, as you are running in an insecure web browser (as you are inside of a desktop app), the desktop app can notice that URL being hit and steal the session token, and at no point did this require a secret key.
Now, if you have a session token, and for some reason you need a secret key for the API you are working with, as you cannot use your secret key (as that would involve disclosing it, which Facebook is very clear you should not ever do), you need to obtain a "temporary session secret key", which you can do by "promoting" your session token, using the client API flow that Facebook tells you to use at this point.
Documentation for the way I happen to know of for promoting a session token is at the following link. (Whether there is a newer way to do this that does not involve activating "legacy APIs" for your application, I do not know.) https://developers.facebook.com/docs/reference/rest/auth.pro...
With the process you described, it would be really easy for apps to simply use another app's id. So, it seems that Facebook has implemented additional measures to prevent this. (e.g. using bundle ID and iTunes app store ID for iPhone apps)
Also, Facebook published iOS SDK that required secret key, but has since updated it to remove that requirement.
This is how every Facebook application works, there's nothing special about distributing the API keys. That's what Facebook tells you to do. Yes you could pretend to be that application - you can do this with every application - and it's not a big deal. Still you can't upload to someone else's account or access their galleries under any circumstances with just the API keys.
"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)."
You fundamentally should not be able "to do this with every application", and you certainly can't with any of the applications that I've deployed (whether for myself, my company, or companies that I've done consulting building these apps for).
(...and yes, I say I'm "rusty" as I'm "out of the game" as it were, but that is mostly because I'm anal about being accurate with my concessions: I have an app right now that has "144,513 monthly active users".)
I don't think the posted content are actually deleted though, they should be unhidden when the app is unblocked.
I can see why people would be bitter... FB just deleted their photos because their upload method was "wrong".
If they said there was no possible way to examine the situation, or that they would restore your photos if you waded through an indemnification click-through, then OK, I can understand.
But just deleting the photos with no warning or even notification?
However: maybe they are doing a great job, and it's just the few mistakes we hear about. Or, even — maybe there's a legitimate reason for banning this application (although they could be better at communicating that reason, if there is one). But, at this point, even just the cases I've heard about here on HN don't inspire me (or, it seems, many others) to choose Facebook as the platform to develop upon. And that might be a bigger issue, even more than application spam.
Edit: after reading saurik's post, this seems like a legitimate situation for them to pull it. However, the point still stands: they need to communicate this better to both KDE and the users of the application.
I like Facebook. Just don't like it when stuff like this happens.
There is also a lot of inertia created from using Facebook for a little while. You can't just pretend that inertia doesn't exist.
Facebook had its chance to redeem itself in my eyes. The attempted Google slander was a tipping point for me, but hearing that my fellow developers are having their apps shut down and their data deleted finally did it for me. I wouldn't have cared if they had just deactivated the app. If it was clear that KDE was leaking its API credentials, I would have done the same thing. But deleting user data is unacceptable.
Yes, you shouldn't rely on Facebook for image storage. But that doesn't mean you shouldn't worry about your data being randomly deleted.
If all you do is upload your primary content directly to Facebook and nowhere else, you're just asking for trouble.
That applies to 99% of the Facebook audience.