What are your “undocumented” APIs up to?
October 23, 2014 Leave a comment
Do you know “Snappening”? It is a story about private Snapchat pictures turning from Casper, the friendly ghost, to a scary Halloween ghost. Recently, there was a second incident at Snapchat in which users had about 200,000 private pictures exposed (mostly pictures of under-aged users, aged from 13-17) online. Most had no knowledge of these photos being stored by anyone. Given the nature of some of those pictures (under aged/minor compromising pictures), these can be considered illegal to possess.
[Image courtesy: Casper’s Scare School]
[Snappening is a little different than the Fappening that occurred a few months ago in which female celebrities’ nude pictures were hacked from iCloud. In that case, the attack was targeted at specific celebrity accounts with a combination of brute force and phishing. Hence, the attack was limited to very few accounts and not massive scale like Snapchat.]
All in all, about 13 GB of Snapchats, which were supposed to have been deleted, were stored without the users’ knowledge by third party applications. These pictures were collected for years using this exploit. In order to understand this issue, we need to dive a bit deeper into what happened.
Snapchat is a media messaging application. You can snap a photo or a video, add a caption, and send it to a friend (or controlled recipient list). After the pre-set time limit (1-10 seconds) the pictures will disappear from the recipient’s device and from the Snapchat servers. It is a good concept as it serves the needy teenage market, which is hungry to share images. Serving that market segment and addressing the privacy/security concerns of the internet seems like a good idea. Where did it go wrong?
Well, apparently, as with most other digital native companies, Snapchat was built with the APIFirst concept in mind. While this is a great idea, you need to be extra careful when you expose those APIs by making them public. Given the hassle that might be involved, especially around security and privacy, Snapchat decided not to make them public APIs, but instead use them only for their own internal purposes, which is very common in the digital industry. Unfortunately, those “undocumented APIs” were left hanging somewhere for others to find and build third party mobile apps on top of them. Given the popularity of the service, lots of third party mobile apps popped up using these undocumented APIs. When you download and start using these apps, neither you nor Snapchat has complete control of the entire situation. A third party app service acted as an intermediary and stored all those images that Snapchat had deleted from its servers. Now, there are conflicting accounts on how those images came out: some say the third party service was hacked and some say the third party service leaked it on purpose.
Snapchat disowned any association with this incident http://blog.snapchat.com/post/99998266095/third-party-applications-and-the-snapchat-api.
The lines that caught my attention from this blog are:
“That’s why we haven’t provided a public API to developers and why we prohibit access to the private API we use to provide our service..”
While it is not the time and place to beat up on Snapchat, being an API expert and an advisor to my customers in avoiding situations such as this, I need to speak up for the others who are doing something similar. It is only a matter of time before your undocumented APIs can be found and exploited. Just because an API provider states in their contract terms, it won’t stop unauthorized developers from exploiting those APIs. Here are some tips on avoiding such a situation:
1. Undocumented APIs need security too.
It is only a matter of time before your undocumented APIs will be exposed and exploited either by someone internal or external. Any good API must have security around it. The first step is to identify the applications that are trying to access it. If a specific third party application is trying to access your service, you need to identify, authenticate, authorize and control the use of service per terms agreed. If your API is a private or undocumented API, then the third party application should not be allowed access to those APIs. Keep in mind security by obscurity never works. Given the tools, needs, and publicity, almost every hacker is going to go after it. Have all the apps (internal or external) that will be using your APIs register first, and agree to terms and conditions, before they are provided with an access key.
2. You can’t visualize or monetize if you don’t monitor it.
The next important step is to monitor your APIs. Not only does this give you an idea of who is using it, and whether they are authorized to use it, but it also gives an understanding of which APIs are popular and measure the traffic patterns. Monitoring allows you to decide the upgrade time frames, maintenance windows, and the usage patterns. Also, if you are not monitoring the usage patterns closely, you will never be able to monetize it properly. If your business model requires you to monetize your APIs, this is an important element you need to have.
3. Undocumented third party apps are a problem.
Beside the security issues, if you are not aware of what the third party apps are using your APIs for, it could lead to an issue when you upgrade your APIs. If you upgrade your APIs and break third party apps, you will get a big backlash from the users. All the apps that use your APIs must be registered and exclusively granted an access key that is unique to that application.
4. Even though your APIs are not documented, you will still be liable for your data.
I discussed this in detail in my “Is your API an asset or a liability?”
5. Impossible to control the wild apps.
It may not be easy to control the apps that are built on top of your undocumented APIs. Snapchat actively monitors app stores (such as google play and Apple store) and asks them to take down the third party apps that are not authorized by Snapchat. While this is a difficult and time consuming process, some of the stores may not even agree to their request as their contract is not with the provider, but with the app developer, which could pose an interesting problem. The app could also be distributed via other means as well which the provider might have no control over.
I recently wrote an article about whether your APIs are an asset or a liability? This is a clear example that your undocumented APIs will be a liability if not managed properly.
A careful design and implementation of APIs, whether public or private, can avoid this situation. As companies build an API first business model, they need to protect their APIs, as their entire business depends on it.
All I can say is this, if you think providing security for your API is costly, imagine how much an incident response and brand reputation management is going to cost you when an event like Snappening occurs?