Several applications on iOS devices like Spotify, Tinder and Pinterest reported crash for a couple of hours last Friday. According to a report by CNN, the outage was caused by a Facebook bug. While Facebook was able to resolve the issue several hours later, social media was abuzz with concerns over the outage.
As many app developers allow users to use their Facebook login information to sign in to other apps, the outage also affected those that did not sign up using Facebook. To understand more about this, CSA reached out to Tim Mackey, Principal Security Consultant at Synopsys Software Integrity Group.
According to Tim, “Modern applications are a combination of proprietary code, open-source software and increasingly third-party APIs. Throw in some configuration settings, and you have an application. Those third-party APIs often do very important things for the application, such as supporting a social media authentication token. Most of the time, this is a good thing since it allows the application developers to focus on making their software really cool and not reinventing something that everybody needs.”
While there has been increasing attention around keeping up with the security of open source components in recent years, the API side of things hasn’t seen as much focus. Tim believes that part has to do with the reality that most API providers want their users to keep using their APIs and will do almost anything to keep the APIs functioning. This, of course, can lead to some serious problems if the API needs to change due to security issues or becomes unavailable for any number of reasons.
“This is exactly what users of popular apps like Spotify, Tinder, and Pinterest, using the Facebook SDK are experiencing. While the Facebook team are working to resolve the issue, this incident highlights an important set of security implications for any app using third-party APIs and SDKs – what happens to your app if the API fails? While some apps are designed to work in airplane mode and have a concept of offline operation, that’s not the same as a critical API failing. When an API fails, the error message returned might be in an unexpected format – say readable to a human but not software.”
Tim explained that when bad data is encountered, the app may crash or perhaps write information to a log file. The crash or log file might contain data that would be helpful to a developer, such as a username or access token. Still, that same helpful information might be classified as personally identifiable under one or more privacy laws.
“This is an example of how a decision made during development could have implications for compliance teams and end users. No business wants to have users complaining about their apps crashing, but things get worse if your legal team needs to be involved.”
Tim pointed out that the problem can be easily solved through the use of ongoing architecture reviews and updated threat models all performed with an eye on external API usage. The threat models will look at the data transferred, and the architecture reviews will look at the behaviour of the app when faced with the unexpected, such as a failed API or transient network connection.